caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Brandon J. Van Every" <vanevery@indiegamedesign.com>
To: "caml" <caml-list@inria.fr>
Subject: RE: [Caml-list] 3D graphics debate
Date: Wed, 9 Jun 2004 01:09:26 -0700	[thread overview]
Message-ID: <OOEALCJCKEBJBIJHCNJDAEGIHDAB.vanevery@indiegamedesign.com> (raw)
In-Reply-To: <200406090340.01133.jdh30@cam.ac.uk>

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


  reply	other threads:[~2004-06-09  8:00 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-07 11:13 [Caml-list] 32 bit floats, SSE instructions Brandon J. Van Every
2004-06-07 11:32 ` Christophe TROESTLER
     [not found]   ` <20040607131717.GA12136@gaia.cc.gatech.edu>
2004-06-07 16:53     ` Christophe TROESTLER
2004-06-07 19:30       ` Brandon J. Van Every
2004-06-07 20:39         ` Nicolas Cannasse
2004-06-08  5:42           ` Brandon J. Van Every
2004-06-08 16:54             ` Jon Harrop
2004-06-08 20:50               ` Brandon J. Van Every
2004-06-09  3:19                 ` skaller
2004-06-08 14:23           ` Keith Wansbrough
2004-06-10 14:43             ` David Brown
2004-06-10 15:20               ` Keith Wansbrough
2004-06-10 15:57                 ` skaller
2004-06-10 16:23                   ` Keith Wansbrough
2004-06-10 16:47                     ` skaller
2004-06-10 19:46                     ` Evan Martin
2004-06-07 21:00         ` Richard Jones
2004-06-07 21:42           ` Jon Harrop
2004-06-09 15:55           ` Richard Jones
2004-06-07 22:48         ` Chris Clearwater
2004-06-07 17:01 ` brogoff
2004-06-08  1:50 ` Brian Hurt
2004-06-08  5:27   ` Brandon J. Van Every
2004-06-08 15:05     ` Brian Hurt
2004-06-08 16:50       ` art yerkes
2004-06-08 17:10     ` Jon Harrop
2004-06-08 19:24       ` Brandon J. Van Every
2004-06-09  0:25         ` Jon Harrop
2004-06-09  1:28           ` [Caml-list] 3D graphics debate Brandon J. Van Every
2004-06-09  2:40             ` Jon Harrop
2004-06-09  8:09               ` Brandon J. Van Every [this message]
2004-06-09  1:33           ` [Caml-list] 32 bit floats, SSE instructions Brandon J. Van Every
2004-06-09  3:04             ` Jon Harrop
2004-06-09  8:33               ` [Caml-list] The multiresolution business model Brandon J. Van Every
2004-06-09  3:27           ` [Caml-list] 32 bit floats, SSE instructions skaller
2004-06-09 14:21             ` Christophe TROESTLER
2004-06-09  2:57         ` [Caml-list] RE: 3D Rendering pipeline Brian Hurt
2004-06-10 17:55           ` [Caml-list] Re: [Ocaml-lib-devel] " Nicolas Cannasse

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=OOEALCJCKEBJBIJHCNJDAEGIHDAB.vanevery@indiegamedesign.com \
    --to=vanevery@indiegamedesign.com \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).