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

["Len Bullard" <cbullard@hiwaay.net>]

Once you have any node on the street, you are more or less stuck with it.
It pays to be stingy with features just as it pays to add one bit at a time
to a world until it works.  Code a little; test a little; get next
requirement.  We know the drill.

That is why they were as parsimonious as they were when the VRML97 design
was done.  Maybe not enough.  I use the Extrusions and ElevationGrids
because the tools made them easy to use.  Now I rely on them and have to
take some nice bits out if they go away.  Those temples use the extrusion
nodes because it was an easy way to create the ganyats that are the base
repeating shape found at every level of a Hindu temple.  The terrains are
obviously elevation grids.  Another effect is also but you won't know that
without looking into the code because it is a non-obvious use.

That and upward compatibility are why standards don't get to start from
scratch.  OTOH, adding lots of nodes isn't a better solution simply for
authoring ease.  That is the definition of bloat.  More is just more until
one can't do something one needs with what one has in the time and with the
skills available.

There is no perfect solution and factoring in the hardware, I don't envy you
those decisions.  VRML started out as HTML for the Web.  Anyone familiar
with the WhatWG vs W3C shootout over the evolution of HTML knows it isn't a
smooth path for HTML these days.  GenCode (as they were warned) isn't
evolvable without a lot of pain for precisely the same reasons as we see
here.  Nodes once fielded get fans and fans create hysteresis (shoes in the
mud).  VRML's designers were smart and added PROTOs, a sweet spot between
OOP and Gencode, because unlike XML, it really is extensible.

I think it a good idea to acknowledge that graphics, particularly real-time
3D will never be as easy as HTML.  I think it a good idea to note and
promote that HTML is not as easy as it was when all pages were gray and
black and no one but a handful of students and DARPA cared.  X3D can't be
all things to everyone either.  On the other hand, I haven't hit the wall
with VRML97 so you are way ahead of me.

Today, guys like me with little or no training but time, patience and your
generosity can build with it and some of the work we do is pretty dammed
good.  People who go to Pacific Tech will always want a lot more.  That's
the Scylla and Charibdis of standards.  Nothing will change there.

It's been a good week.  Errors are being found, lack of coherence in the
error reporting is being uncovered, and I just got Kamala to behave as I
need her to.  Good luck with your debates on nodes.   It comes down to the
markets you need to support.  I'm just a hitchhiker.  Thanks for the ride.

len


From: owner-x3d-public@web3d.org [mailto:owner-x3d-public@web3d.org] On
Behalf Of Dave A
 
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





-------------------------------------------------------------------------
for list subscription/unsubscription,
go to http://www.web3d.org/cgi-bin/public_list_signup/lwgate/listsavail.html