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

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



Hi John, Don and All
 
I agree that for some tasks it makes sense to let the tool do the optimizing
but this depends on what the issue is.
We still compile code into machine code in the end because low level offers
more power and versatility than high level code.
For high level GUI editors you leave more possibilities open if the format is powerful
and therefore low level formats are more likely to be welcomed by both newbies and
advanced users in the long term unless perhaps the newbie wants to hand code and
this too would depend on how the format has been designed.
Bjarne Stroustrup makes a point that it makes little sense to add built in high level
features to a general purpose language if the language is already capable of utilising
low level building blocks to create higher level building blocks for the programmer.
This is the philosophy of designing for extensibility instead of built in specialisation.
 
regards
 
thyme
----- Original Message -----
Sent: Thursday, December 21, 2006 1: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.

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