[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [x3d-public] Shaders and Triangles: was dedicated working-group focus on X3D interoperability
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?
Easiest thing for content authors (short of a drag/drop wysiwyg IDE), is to never worry about
stuff that can be computed for them, at the risk of longer load times and/or undesired effects.
So the middle ground is where this needs to stay, with a bias that gets you to a goal
of (what?) more universal acceptance? That's leaning toward content-easy. Best performing?
Give it up, that's games, and they pre-compile to efficient representations.
Which is where I'm tending to think things need to go.
a) tools optionally auto-compute and output things that can make the content more efficient
b) browsers optionally pre-compute (and cache) things not provided in the content. As this
is done for lack-of-Normals, similar things could be done to analyze an IFS and determine
if it's really a strip or fan or whatever. CPU's are fast these days. Given the
inherent delays of getting content across a network, a few milliseconds ain't gonna bother
me, so hey, let's look at some alg's
Dave A.
Len Bullard wrote:
Mostly they tolerate the authors pretty well, but I suspect that the drivers
these days are contracts for ever more performant large applications for big
customers. I can't fault them for that.
OTOH, when the tools can't agree on what a syntax error is and what to do
with it, they have more basic problems. BS Contact tolerates a lot of
syntax slop and that suggests they have been favoring the authors and the
large multi-contributor worlds. Flux and Chisel are pretty hard on the
syntax errors. That suggests they are trying to keep the whole ecology
running smoothly but that the authors have to do their bit too by writing
correct code. As a result, BS Contact is not a good browser for testing
worlds; it is a good browser for fielding them. The exact opposite happens
with Flux and Chisel.
If all of a sudden, a lot of worlds stopped working because nodes were
withdrawn in the pursuit of closer-to-the-metal performance, that would be a
big mistake.
Beware pleioptropy. Cave fish are blind because of the lack of light, but
not as a direct effect. It isn't that lack of light affects the evolution
of their eyes. Their eyes go away because the same transcription genetic
message that favors longer jaws and thus finding food in the dark also
causes the eye to quit developing. So the apparent cause is not the real
one. It's an accidental coupling. It bedeviled geneticists for years until
they realized they were making superstitious assumptions about the linkage
of environment to feature. It was there but they guessed at a linkage that
didn't exist.
I'd beware of optimizing for speed in pursuit of more authors. We deal
with the nodes as they are because we only learn them as we use them.
Advanced authors do advanced jobs. The rest of us learn from them.
If you want that to satisfy paying customers, I can only say, don't make the
rest of us blind just because we are fish instead of beef.
len
From: owner-x3d-public@web3d.org [mailto:owner-x3d-public@web3d.org] On
Behalf Of Dave A
With this and other threads going around, it seems to me that the question
being asked is: for whom should X3D be easy for: browser/plugin programmers,
or content authors. My vote: content authors. Unfortunately, the spec
has largely been driven by browser programmers. This IMHO is why X3D has
been problematic.
-------------------------------------------------------------------------
for list subscription/unsubscription,
go to http://www.web3d.org/cgi-bin/public_list_signup/lwgate/listsavail.html