Re: [x3d-public] Shaders and Triangles: was dedicated working-group focus on X3D interoperability

[Dave A <dave.arendash@corp.manyone.net>]

I would not want to dump any of the real primitives. In fact, I'd like to see
a Plane which would just be a simple quad polygon, as they are sooooo handy.
I mean, you got a Box, so why not. But with some goading, Flux Studio may
have a plane-maker some day ;-)

I'm not sure that roundy bits are always going to be triangulated (or whatever).
There may be hardware or shaders that can truly digest a sphere or cone for
optimal rendering. Plus they're also damned handy. Very portable.

ElevationGrids - in their current incarnation - are nearly useless to me, as
all the quads are split in the same direction, and I need to be able to cut
some of them in the opposite direction. Or render as curved surfaces. And
they need to be bigger somehow. I know perhaps the hardware can't eat something
larger than 128x128. That's where, again, I'd like to see more smarts in
the tools and/or the browser, to break things up into whatever works best on
the current platform, and/or 'hint' fields to help the browser decide what to do.

Dave A

Alan Hudson wrote:
> Dave A wrote:
> > Len and Alan: good points all, well taken
> >
> > I can see some need for the fine control of specifying how something 
> > gets into the hardware
> > (triangle-whatnots vs IFS), but I'd rather see field creep rather than 
> > node creep, where
> > possible. IFS with 'tesselationHint' = "TRIFAN" "TRISTRIP" "DONTCARE" 
> > etc, for example.
> > Like Normals are at the moment (admired but not required).
> > And if things get tough for the brower programmers, ask for help! 
> > Perhaps there's some
> > code or algorithms floating around somewhere someone can contribute.
> > Taken to absurd extremes, the easiest thing for browser programmers 
> > (god bless 'em, by the way)
> > is to just deal with lowest-level stuff. Then why have a high-level 
> > language at all?
>
> The triangle nodes were not added to make implementation easier.  In 
> fact they were more work.  They were added to give X3D programmers a 
> more effecient way of greating dynamic content.  IFS is just not that 
> effecient a way of specifying geometry.
>
> John's point is well taken, keep the language simple.  I'd suggest the 
> trade is worthwhile in this case as it enables us to avoid a whole bunch 
> of other nodes.  In theory(and this is where it gets interesting) we 
> don't need Nurbs, Extrusions, ElevationGrid, Sphere, Box et el as we 
> have an extensible way of creating geometry now.  Ie a set of PROTO's 
> could be provided that implemented these things and they wouldn't need 
> to be in the base spec.
>
> Of course likely that would look like script code stored someplace on 
> Web3D.org.  What language, ecmascript?  Could do but its not as 
> effecient as I'd like for really large worlds...
>
> So we still end up with some higher-order nodes.  But maybe we don't 
> have to.
>
> IFS seems too complicated to be the base building block.  It can do most 
> everything(strips and fans excluded for now).  But its a big hammer.
-------------------------------------------------------------------------
for list subscription/unsubscription,
go to http://www.web3d.org/cgi-bin/public_list_signup/lwgate/listsavail.html