From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id KAA24584; Wed, 9 Jun 2004 10:00:00 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id JAA24178 for ; Wed, 9 Jun 2004 09:59:59 +0200 (MET DST) Received: from outbound28-2.lax.untd.com (outbound28-2.lax.untd.com [64.136.28.160]) by nez-perce.inria.fr (8.12.10/8.12.10) with SMTP id i597xvEV028823 for ; Wed, 9 Jun 2004 09:59:57 +0200 Received: from outbound28-2.lax.untd.com (smtp01.lax.untd.com [10.130.24.121]) by smtpout03.lax.untd.com with SMTP id AABANPS5YASXE7HA for (sender ); Wed, 9 Jun 2004 00:59:50 -0700 (PDT) Received: (qmail 11404 invoked from network); 9 Jun 2004 07:59:41 -0000 Received: from 66-52-204-29.sttl.dial.netzero.com (HELO vangogh) (66.52.204.29) by smtp01.lax.untd.com with SMTP; 9 Jun 2004 07:59:41 -0000 From: "Brandon J. Van Every" To: "caml" Subject: RE: [Caml-list] 3D graphics debate Date: Wed, 9 Jun 2004 01:09:26 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <200406090340.01133.jdh30@cam.ac.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-ContentStamp: 16:8:3927991117 X-MAIL-INFO: 46d4d17d75d0f4695164e0c58419b17d9d4059054549adc9ad548d8de915bde004a01571bd49bda9d975150c24002061a469494d142d0dd531f5f424ed30ed557d7d7970b5891db47091b524b56ddd34919070091401b0a1e0b9d085bd7115bd7504497561212d6125251125d9859d85a9303029596005741959c060d960b1e1b579e1097091091da1241da4a4d1 X-UNTD-OriginStamp: CI84cOLHFqh7Zd2QWkwvEFvwyO3T/pIsPQZphDk9MRj21pHrcTmBt8o3yd2Z0y5s X-Miltered: at nez-perce with ID 40C6C37D.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; brandon:99 caml-list:01 brandon:99 abstraction:01 reordering:01 irritating:01 abstractions:01 tweak:01 dynamically:01 lod:99 floats:01 obsessed:01 planets:01 repetitive:01 planets:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk For the uninitated, what you are about to witness is best described as a 'culture clash'. On the one hand you have Mr. PhD, represented by John Harrop. On the other you have an almost totally self-taught erstwhile optimization jock, represented by yours truly. Jon Harrop wrote: > Brandon J. Van Every wrote: > > Joh Harrop wrote: > > > > > > I think you are exaggerating cost of the "abstraction" of > > > reordering the arguments of a function. > > > > And I'm thinking you've never done high performance > > anything in a big > > architecture for a living. Prove me wrong. > > Oh ok then - I've just passed my PhD in computational and > theoretical physics from the University of Cambridge. Thank you for finally showing your true colors. It is irritating to waste time with people who give the appearance of knowing nothing about 3D graphics performance, yet have lotsa suggestions about why AoS vs. SoA "really doesn't matter." Frankly, you either know why it matters and have been pulling my leg, or you are too far into the abstractions of your problem domain to care about the performance implications of low level 3D operations. I suspect that happens frequently to researchers whose products never become industrially mature, and consequently never have code monkeys seeking to tweak the hell out of their basic architectures. You prototype, you ain't optimizing. > One is a multiresolution representation of a planet which is > dynamically tesselated to give just enough detail for rendering: > > http://www.chem.pwf.cam.ac.uk/~jdh30/programming/opengl/lod/index.html > > if the planet were represented to enough detail using flat > data structures > (equivalent to the cell grid) for that demo it would require > 2^80 floats. Had > I known OCaml at the time, this would have been a much > smaller and faster program. :-) I've obsessed about rendering planets the size of Mars (roughly 1/4 surface area of Earth) down to 10 km/hex detail on a GeForce2. With each hex containing unique type data, not some fractal repetitive thing. It is too much detail to actually see and use in a game (your website indicates interest in games). I am not impressed with your argument about "flat data structures," at least not from what you have given above. To make a game is about controlling visualization and zoom, so that the data is actually usable. I've worked on hierarchical methods, compatible with spherical hexified icosahedral topologies. Too much hierarchy, you ain't gonna get through the rendering or the game. If you consider the terrain mapping of *real* planets, with real unique surface data, you have a lot more to consider. My planet was only a game planet, at a relatively coarse resolution, but it was all unique data. All of your subtriangle stuff is stuff I've considered and abandoned as too complex in the real world to implement a game, after reams and reams of paper expended, and some code too. A *game* surface has to be addressable and fundamentally usable as a programming API for other things, like the AI code. I went with Barycentric coordinates and that proved to be a mistake. Too complex. My next attempt will not be based on the polygonally segmented icosahedron, but rather, upon a generalized error reduction mesh with a simple grid for rapid lookup. > Aren't we talking about a 4xn matrix rather than an nx4 matrix? I don't even know why the hell you started talking about matrix anything. The vast majority of problems I've encountered in 3D graphics are ad hoc accept / reject processing. > > > Can these algorithms not be transformed so that they > > > access more coherently? > > > > No, dammit! You Just Don't Get It [TM]. When someone tells you > > something is "an invasive programming model," they're telling you > > they're not looking for the opportunity to rewrite their > > whole software > > architecture from scratch just because you personally think > > SoA might be more kewl than AoS. > > Well, if you want to optimise your program and you wrote it > badly the first time... ;-) "Your program?" Have you simply never worked in an industrial capacity? Where did you get this UberDesigner control over "your program?" > I would say that I am somewhat familiar with the concepts > involved. My concern > is that I have only ever come across your optimisation > problems in the > context of shoehorning algorithms into using flat containers. Maybe you just don't think very well in terms of flat containers and that's Your Nature [TM]. It is certainly not my nature to envision 3D graphics problems as hierarchies, unless they're exceedingly flat hierarchies. I can definitely point to some problems where my approach is appropriate and yours isn't. In other scenarios it's a matter of personal style, and I generally put my money on "simple implementation, rely on 3D HW to speed up linearly." For instance, a simple grid for planetary addressing in buckets rather than your elaborate hierarchical lookups. > > So was it 'dabbler' or not then? I suppose you think that the > > implementation complexity of multiresolution representations is > > desireable in an industry where a significantly faster card > > ships every 6 months? > > Absolutely. It separates the men from the boys... In terms of "I'm some badass algorithm guy," or in terms of "I can actually ship product and make profit?" Here we separate the ivory tower from industrial reality. Cheers, www.indiegamedesign.com Brandon Van Every Seattle, WA "We live in a world of very bright people building crappy software with total shit for tools and process." - Ed Mckenzie --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.693 / Virus Database: 454 - Release Date: 5/31/2004 ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners