[x3d-public] Non-Hand Coding of X3D

John Carlson yottzumm at gmail.com
Thu Feb 25 12:16:28 PST 2016


You need to look at enter() more and how it works with the other functions.  It’s more than just append or addChildren.  It joins data with the scenegraph.   D3.js also has append().

Note that you can use values from data or functions taking data to “style" the scenegraph after you use enter().  Note that this *is* similar to JQuery’s append(function), but you can also pass  data, not just an old html string or an index to a subsequent append() lambda function parameter after enter().  Yes, I realize you can use the index to look up the data, but it breaks encapsulation.

So for example, I could style repeated parts of the scene graph with a function that would specify different colors for each part.  Or I could transition from one color to another color.

https://github.com/mbostock/d3/wiki/Selections#enter <https://github.com/mbostock/d3/wiki/Selections#enter>
https://github.com/mbostock/d3/wiki/Selections#append <https://github.com/mbostock/d3/wiki/Selections#append>

Enter works with data() to import data.

This isn’t some dumb JQuery thing, it’s genius—making full use of lambda functions.  But you an probably emulate it with $.each and $.append with some work.

Anyway, I can probably use D3.js.  I was just thinking of an XML syntax…probably can use templates.

It’s almost like a collection decorator.  You decorate your data with a scenegraph, instead of populating your scenegraph with data.

John
> On Feb 25, 2016, at 9:28 AM, Leonard Daly <Leonard.Daly at realism.com> wrote:
> 
> On 2/24/2016 7:26 PM, John Carlson wrote:
>> It would be cool if X3D had an .enter() function like D3.js to add and update nodes from data.  I think there’s .exit().remove() to for removing nodes.  This makes your data work extremely well with creating and removing visualization objects.  <https://bl.ocks.org/mbostock/3808218>https://bl.ocks.org/mbostock/3808218 <https://bl.ocks.org/mbostock/3808218>  This might be done by attaching data to a MACRO (the MACRO being enter()).
> 
> 
> When running in a DOM integrated environment (e.g., X3DOM), there is the DOM method .addChildren. jQuery methods also work. When running in pure V3 X3D many nodes have the field addChildren. Field values can be changed with events and directOutput.
> 
> 
> Leonard Daly
> 
> 
> 
> 
>> 
>> On Feb 24, 2016, at 9:01 PM, Leonard Daly < <mailto:Leonard.Daly at realism.com>Leonard.Daly at realism.com <mailto:Leonard.Daly at realism.com>> wrote:
>>> 
>>> John,
>>> 
>>> Just to address a few of your points. 
>>> 
>>> I don't see the functionality currently available with PROTOs and Scripts going away. I see it increasing because HTML Scripts can easily add nodes to the DOM. There have been several discussions on the topic of PROTOs. I see a proto-expander or MACRO as being a great addition to V4. It is also possible to easily provide that sort of service via an HTML Script or new custom-implemented node. If the new node is a collection of existing nodes (say Yves pyramid node), then the supporting code to create and parse that node is very easy to write in X3DOM.
>>> 
>>> I can see a shared library of useful nodes that sites on top of X3D and is available to the user as either nodes or HTML scripts.
>>> 
>>> I would like to see X3D accept a wide variety of data formats, even if some translation/conversion needs to occur. Using InstantReality it is possible to go from X3D, OBJ, FBX and perhaps others to SRC. SRC is a good format for injestion because it moves quickly to WebGL. X3D is to remain ISO standardized. No other 3D format and run-time can state that.
>>> 
>>> Animation is a current problem. The SRC does not hold animations. The only widely used format that does combined with model data is FBX. That is something that needs to be developed, but there are several things that need to come first.
>>> 
>>> 
>>> Leonard Daly
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> You make good points Leonard.  How would you differentiate V4 from Collada in that case?    My understanding is that X3D provides for declarative app development. This is one reason we are moving towards the web, to open X3D up to more app developers.  What is important for declarative app development?  Protos, Templates, Web Components and associated scripts, essentially *shared behavior*.  If you have a virtual world, you might certainly have exactly one of everything.  However, it’s easier to instantiate Protos or Templates, I think.   The trick is to only mention the creation a few times (once) with templates or web components, and let the environment expand it into multiple instances through templated transforms and parameterization.  I don’t want to see 400 ProtoInstances of cylinders in code, unless it’s generated (HTML).  X3D *should* be associated with a data format for pure data, like D3.js has several, and transforming pure data into 3D.  I know I have different requirements, but I think X3D V4 should be designed for scaling things up—not only shapes and transforms, but coordinates and polygons as well (SRC). Is any other format in position to provide for such scaling without killing memory or diskspace?  Models are certainly moving towards SRC. If you are concerned about animation, what’s the best way to provide for animation coming from these tools?   We have your proposed nodes.  Are these sufficient?   Should we start looking more at creating exporters for animation beyond just models?  What animation exporters to X3D are already out there?
>>>> 
>>>> John
>>>> 
>>>>> On Feb 24, 2016, at 7:55 PM, Leonard Daly < <mailto:Leonard.Daly at realism.com>Leonard.Daly at realism.com <mailto:Leonard.Daly at realism.com>> wrote:
>>>>> 
>>>>> There seems to be some confusion about my statements about not hand-coding certain things. 
>>>>> 
>>>>> I have stated that models and animations are not hand-coded anymore. That statement does not mean it can't be done, but there are many tools that do it, including open-source ones. There is no way someone is going to hand-code models such as you can see at http://www.blendswap.com/blends/index <http://www.blendswap.com/blends/index>. Hand coding models to be printed is also not a good idea because things will probably not line up correctly.
>>>>> 
>>>>> Animation is the same thing. Yes you can animate by hand-coding all of the motions and deformations, but that is not how it is done. If X3D is to get any acceptance into the professional marketplace it MUST work with application generated models and animations. There will still be some important animations that are hand coded (e.g., camera motions, automated systems, etc.). 
>>>>> 
>>>>> Nothing I have done in working out the V4 proposal precludes hand-coding of animation or modeling. It does not provide a lot of convenience features/nodes to make complex work simple. In the marketplace, it is much simpler to get someone to do the model or animation in a tool. 
>>>>> 
>>>>> 
>>>>> -- 
>>>>> Leonard Daly
>>>>> 3D Systems & Cloud Consultant
>>>>> X3D Co-Chair on Sabbatical
>>>>> LA ACM SIGGRAPH Chair
>>>>> President, Daly Realism - Creating the Future
>>>>> _______________________________________________
>>>>> x3d-public mailing list
>>>>> x3d-public at web3d.org <mailto:x3d-public at web3d.org>
>>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org <http://web3d.org/mailman/listinfo/x3d-public_web3d.org>
>>>> 
>>> 
>>> 
>>> -- 
>>> Leonard Daly
>>> 3D Systems & Cloud Consultant
>>> X3D Co-Chair on Sabbatical
>>> LA ACM SIGGRAPH Chair
>>> President, Daly Realism - Creating the Future
>> 
> 
> 
> -- 
> Leonard Daly
> 3D Systems & Cloud Consultant
> X3D Co-Chair on Sabbatical
> LA ACM SIGGRAPH Chair
> President, Daly Realism - Creating the Future

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20160225/a400c62b/attachment-0001.html>


More information about the x3d-public mailing list