[x3d-public] x3d nodes as DOM nodes [was: Non-Hand Coding of X3D ]

Wed Feb 24 20:50:54 PST 2016

One advantage of integrating x3d nodes as DOM nodes is that they can be
manipulated in the same way and by the same tools as other DOM nodes,
including D3. So it should not be necessary to explicitly add .enter and
such to the spec. or API . It only should be necessary to spell out that
X3D nodes can be manipulated using the standard DOM API, just like other
nodes such as svg or table. Then tools like D3 or jquery will work with x3d
nodes, like they work today with x3dom nodes.

While to me it is self evident that the web platform is the most relevant
platform for X3D - after all vrml has URLs - I want to point out that from
what I have seen most VR development takes currently place as standalone
apps using Unity, distributed from tightly controlled app stores. Such a
distribution model fits standalone X3D browsers better, once they have a VR
mode.
But once 3d gets more common on the web, there will be an expectation that
VR is also available and perhaps somehow integrated with other web content.

Andreas
On Feb 24, 2016 10:26 PM, <x3d-public-request at web3d.org> wrote:

Send x3d-public mailing list submissions to
        x3d-public at web3d.org

To subscribe or unsubscribe via the World Wide Web, visit
        http://web3d.org/mailman/listinfo/x3d-public_web3d.org
or, via email, send a message with subject or body 'help' to
        x3d-public-request at web3d.org

You can reach the person managing the list at
        x3d-public-owner at web3d.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of x3d-public digest..."

Today's Topics:

   1. Re: Non-Hand Coding of X3D (Leonard Daly)
   2. Re: Non-Hand Coding of X3D (John Carlson)

----------------------------------------------------------------------

Message: 1
Date: Wed, 24 Feb 2016 18:01:47 -0800
From: Leonard Daly <Leonard.Daly at realism.com>
To: John Carlson <yottzumm at gmail.com>
Cc: X3D Graphics public mailing list <x3d-public at web3d.org>
Subject: Re: [x3d-public] Non-Hand Coding of X3D
Message-ID: <56CE608B.6000501 at realism.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

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 <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. 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
>

--
*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/20160224/37e79dac/attachment-0001.html
>

------------------------------

Message: 2
Date: Wed, 24 Feb 2016 22:26:10 -0500
From: John Carlson <yottzumm at gmail.com>
To: Leonard Daly <Leonard.Daly at realism.com>
Cc: X3D Graphics public mailing list <x3d-public at web3d.org>
Subject: Re: [x3d-public] Non-Hand Coding of X3D
Message-ID: <7D6472CF-CF81-4AB3-8911-7A465CFF570E at gmail.com>
Content-Type: text/plain; charset="utf-8"

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>  This might be done by attaching data
to a MACRO (the MACRO being enter()).

On Feb 24, 2016, at 9:01 PM, Leonard Daly <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 <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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20160224/3f2cfb59/attachment.html
>

------------------------------

Subject: Digest Footer

_______________________________________________
x3d-public mailing list
x3d-public at web3d.org
http://web3d.org/mailman/listinfo/x3d-public_web3d.org

------------------------------

End of x3d-public Digest, Vol 83, Issue 69
******************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20160224/9046d0e5/attachment-0001.html>