[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [x3d-public] dedicated working-group focus on X3D interoperability

John A. Stewart stated:

Quite simply put, all of the Triangle and *2D nodes could be dispensed
with. Same with some others.


Please consult the folks making authoring tools about this.
Are some of those other 'Same as' thingies items like
import/export, event utils, nurbs, and shaders?  SAI?
The 'Triangle and *2D nodes' have got to be among the
easiest of new X3D features to implement since they
are much closer to the OGL and DX metal than ifs.
Any browser is free to state exactly what they will support.
Do you mean to drop some components from some profile?

Focus should be on optimization techniques
to render shapes quickly, on given hardware.


imo, this is the last consideration for X3D.
The focus is to provide a standard basis for authoring tools
and players that work over a wide range of hardware and
software platforms.

X3D has missed the mark of abstracting the details of the graphics
implementations from the users.


For this we need an example. How can we better abstract X3D
layers or lighting, for example?

If one can infer a relationship with computing languages,  We are
producing
a "super assembler" - one that can do anything. The world, except for
certain
real time programming, does not use assemblers any more;


I would suggest that the basic design of X3D is to enable
a scriptable real time environment.
Thus, I do not understand the comment.

That's not correct - we should be making
the job of the authors (and, authoring programs) easier.


Great statement. We have to provide a platform that allows
authoring systems to provide even greater abstractions than
the fundamental language elements - to hook things together
and make the best choices for presenting shapes and
interactivity. And, they need to export X3D.
The added geometries give the authoring tools greater choice,

The
end goal
is to perform runtime optimizations on the data;


That is a great goal, for some applications. It is not a goal of
the X3D standard and should not be relevant in X3D conformance
testing.

We are
not quite at performing major runtime optimizations yet; but it will
come.


Don't optimize too early:) Get a faster computer instead.
Please recall that we wish for a live scene graph and a
live behavior graph.
I would request work on the SAI over 'runtime optimization'
at this time. Without consideration of all X3D shape and texture
elements and layers and related stuff, and, as _n points out,
without an intimate understanding of the underlying isosurface
conceptions, there may be dead ends there.

If you, or anyone else on the
recipients
list wishes to discuss this further, please email.


I hope you mean this list.

Thank You and Best Regards,
Joe



----- Original Message ----- From: "John A. Stewart" <alex.stewart@crc.ca>
To: "Don Brutzman" <brutzman@nps.navy.mil>
Cc: "X3D Graphics public mailing list" <x3d-public@web3d.org>; "Web3D Consortium Members" <consortium@web3d.org>
Sent: Wednesday, December 20, 2006 6:38 AM
Subject: Re: [x3d-public] dedicated working-group focus on X3D interoperability


Don;

Congratulations on this working group, and of the moratorium on new
nodes. Most certainly, the number of nodes in X3D, and the rate they
are being placed, is staggering.

Can I email my thoughts on this?

Athough FreeWRL tries to support as many nodes as possible, I think
that the X3D "problem" could be solved differently. This view comes
from many years of hacking about with FreeWRL.

Quite simply put, all of the Triangle and *2D nodes could be dispensed
with. Same with some others. Focus should be on optimization techniques
to render shapes quickly, on given hardware.

What we appear to be doing is to move that optimization level up the
food
chain; making our job easier. That's not correct - we should be making
the job of the authors (and, authoring programs) easier.

X3D has missed the mark of abstracting the details of the graphics
implementations from the users. It should be up to the browser
implementer
as to how to best send the data to particular hardware.

If one can infer a relationship with computing languages,  We are
producing
a "super assembler" - one that can do anything. The world, except for
certain
real time programming, does not use assemblers any more; it's much
easier
to write in Java or C or whatever, even if it is maybe not as
efficient. When we
write in Java or C, we expect the compiler/interpreter to make
optimizations for
us *that fit with the current hardware*.

X3D seems to have missed that point.

FreeWRL, by the way, treats most geometry identical internally.  The
end goal
is to perform runtime optimizations on the data; whether that data comes
from an Extrusion, ElevationGrid, IFS, TriangleSet, Mesh, whatever.
We are
not quite at performing major runtime optimizations yet; but it will
come.

Anyway, my two cents (Canadian :-); If you, or anyone else on the
recipients
list wishes to discuss this further, please email.


-----------------------------------------------------------
John A. Stewart
Team Leader: Networked Virtual Reality.
alex.stewart@crc.ca

Network Systems and Technologies -
        Systemes et technologies des reseaux
Communications Research Centre Canada  |
         Centre de recherches sur les communications Canada

3701 Carling Ave.  |  3701, avenue Carling
PO Box 11490, Station H  |  CP 11490, succursale H
         Ottawa ON K2H 8S2   |  Ottawa (Ontario) K2H 8S2

http://www.crc.ca







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