[x3d-public] Issue: X3D V4 Functionality

Kristian Sons kristian.sons at dfki.de
Wed Jul 15 04:21:36 PDT 2015


I completely agree to Max!

However, the IndexedFaceSet is a very high-level convenience node. It 
requires a lot of processing to convert an IndexedFacSet into a 
GPU-friendly representation. I attached an image displaying the data 
processing required according to the representation. This does not even 
include the vertext splitting required due to the fact that there are no 
multiple indexes in WebGL (at least without a geometry shader). BTW, 
this is very similar to COLLADA nodes and why Khronos introduced the 
glTF representation.

In XML3D we have this very minimal subset of necessary node. For 
instance, the <mesh> element represents a list of WebGL primitives and 
can be translated to WebGL buffers as-is. An IndexedFacetSet would be a 
<mesh> node plus one or more Xflow nodes that does the required 
processing. The main difference is that required processing is explicit 
and not somewhere hidden in the system.

We were already playing around with the idea to show if XML3D is 
feature-complete to be able to map a X3D scene graph to XML3D without 
loss of information.


Am 10.07.2015 um 00:25 schrieb Limper, Max:
> I really like the idea of identifying "convenience nodes"!
> This should help us to define a minimal subset for HTML. X3DOM already has some nodes that are not really necessary, so it could make sense to also check X3DOM for convenience nodes that could be removed from the HTML Profile.
> Regards,
> Max
> Am 09.07.2015 3:23 nachm. schrieb doug sanden <highaspirations at hotmail.com>:
>> How do we determine what should be in the HTML Profile of X3D V4?
> Option 1: if a node can be automatically generated from another node, then its a convenience node
> In desktop x3d some nodes are 'convenience' nodes. Extrusions simplify indexedfacesets.
> One thought is to eliminate all convenience nodes from html profile, if a transform can be done automatically:
> convenience node -> automatic transform -> primitive node
> Then if someone has a desktop x3d scene, they can upload it to a cloud facility that automatically converts it to html profile compliant.
> Option 2: As-is
> The gurus working on x3dom invested their time and life, and they want to make it popular/a success,, and their judgement about tradeoffs can be trusted, so ask them. Or -since their judgement went into the current distro of x3dom- simply document the current distro as the defacto x3d html standard.
> I suspect unlike native browsers, there will be few ground-up competitors to x3dom, so when you are documenting standards, its primarily for authoring tools.
> -Doug
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org


Kristian Sons
Deutsches Forschungszentrum für Künstliche Intelligenz GmbH, DFKI
Agenten und Simulierte Realität
Campus, Geb. D 3 2, Raum 0.77
66123 Saarbrücken, Germany

Phone: +49 681 85775-3833
Phone: +49 681 302-3833
Fax:   +49 681 85775–2235
kristian.sons at dfki.de

Geschäftsführung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender)
Dr. Walter Olthoff

Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313

-------------- next part --------------
A non-text attachment was scrubbed...
Name: IndexedFaceSet.png
Type: image/png
Size: 899833 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20150715/3feed591/attachment-0001.png>

More information about the x3d-public mailing list