[x3d-public] Field access in V4.0 geometric nodes; torus

[Don Brutzman]

On 2/25/2016 3:59 AM, Yves Piguet wrote:
> The new Torus node in V4.0 specifies inputOutput access for innerRadius, outerRadius etc. Does it mean that the size fields of all geometric nodes will be changed from initializeOnly (as specified in <http://www.web3d.org/documents/specifications/19775-1/V3.3/>) to inputOutput? (e.g. radius in Sphere)
>
> Thanks,
>
> Yves

Hi Yves.  There are multiple aspects to your question.

1. First, no Torus node has yet been proposed to the X3D Working Group.  It can be added if there is sufficient interest and consensus that it adds value, rather than bloat if too many nodes get added to the core spec.  A number of tradeoffs are always considered - it's all good.

The X3D v4 page provides a top-level overview of past and planned work.

	http://www.web3d.org/x3d4

The X3D version 4.0 Development page lists many details about what is being considered.  Suggestions and proposals are welcome.

	http://www.web3d.org/wiki/index.php/X3D_version_4.0_Development

2. Next there are a number of Torus implementations out there.  X3DOM has one:

	http://doc.x3dom.org/author/Geometry3D/Torus.html

A search for "X3D torus" reveals others.  Several are in the open-source archives.

	http://www.web3d.org/x3d/content/examples/Basic/course/
	Extrusion Cross Section Example Torus

	http://www.web3d.org/x3d/content/examples/Vrml2.0Sourcebook/Chapter15-Extrusion/
	Figure 15.12 Torus
	Figure 15.12 Torus With Axes

	http://www.web3d.org/x3d/content/examples/Vrml2.0Sourcebook/Chapter17-Textures/
	Figure 17.09b Textured Donut Torus Extrusion

Inspection reveals that Extrusion is commonly used to create a torus.  This can lead to questions like

- why add Torus (and maybe many others) if Extrusion is already suitable?
- Torus can have a wide range of resolutions, should the node be fixed or flexible?
- why can't an author use a NURBS surface instead?

It wouldn't be that hard to write an Extrusion prototype, which would be portable among most players.

Incidentally the Extrusion editor in X3D-Edit makes it easy for an author to pick the resolution they want by defining n for an n-sided polygon.

3. Next, regarding accessType. The usual rationale for a geometry "primitive" node is to let the player do the geometric computation as they see fit.  This allows a variety of tesselation or surface refinement schemes under the hood.  This also lets players store in an efficient manner as they see fit, independent of anyone else.  So once again, interesting tradeoffs.

That is why you see accessType="initializeOnly" for many primitive fields.  The player gets to decide to create and store as they see fit.  Not including recomputability means that the node is suitable for Interchange Profile and can run on small memory-limited power-limited devices with little overhead.  Meanwhile an author can use Transform scale at run time to easily change/animate a primitive node.

So no, given that proven balance between authors and player engines and user devices and X3D profiles, we probably shouldn't expect that the existing primitive geometry nodes will have accessType changes.

Hope that helps.  Who knew that primitives aren't that primitive after all?  8)

all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman