[x3d-public] Non-Hand Coding of X3D

[Joe D Williams]

Great stuff. If you have only slightly more than a passing 
acquaintance wit realtime interactive animated 3D graphics, there is 
no worthwhile scene that is not in part hand-coded (or the majority if 
copy paste is part of hand--coding.
If you cannot use a text eidtor on whatever user code is emmitted from 
whatever tool, then I mean its like being an html expert using only 
Dreamweaver or Frontpage.

If you have a tool made with X3D in mind, meaning that X3D was lucky 
enough to pick off some of the prime features of the tool, then all is 
much better. Too bad many of those tools made for VRML/X3D, like flux 
and viz are in hiding. Talk to your toolmaker and tell them you want 
to export X3D in some form and they might tell you how to make it more 
simple. Because the most simple way to export stuff is like rendering 
for film where the output for each frame is the entire precomputed set 
of vertices and supporting data for each frame without the idea of 
interpolators, aim for realtime which means you have the stuff drawn 
and now you just need to move it to determined locations at the time 
appropriate in the particular live scene.

Fiirst step: Since all the tools use basically the same stuff with 
different names and different formats or encodings, first try to align 
the authoring and export tool to our beloved X3D.  Start simple with 
export of geometries and textures. Most importantly do your cleanups, 
before exporting. If animating, be sure the tool can provide user code 
for interpolators and timers - believe me they all do but may be 
hidden or deep. Next, if you are picking stuff up from lilbraries, 
plan of converting shapes from whatever to some X3D. Most mature tools 
will not have a problem with this if you can find the correct 
settings.

Sure, that means maybe eliminating some of the proprietary features of 
some tool but Hey, it is X3D not the 10K$ per seat CG.wiz that gabe us 
most of the pieces we now have. In certain ways you will find that a 
typical major tool in its native code is more or less forgiving than 
an X3D player which is more likely to demand that all things are 
completely correct

If the authoring tool is mainly set up for film and video outputs, 
then carefully check that it will give you interpolators and 
axis-angle (or quaternion) rotations. It may be better to export some 
kinds of stuff to Collada or SRC or GLtf then fix some syntax with a 
text editor before putting it in the X3D scene. Before you export the 
stuff, massage it so that it is realistic with respect to X3D, that is 
dimensions in meters. Zero everything in place. Don't depend upon a 
bunch of 'convenient' scales and transforms to make things fit in.

If you are working a humanoid (like Biped), then especially get the 
size of the thing in human space. Build the skeleton in realistic X3D 
humanoid skeleton space. Dimension everything in human space and don't 
use sets of scales and transforms to fit the parts, draw them in human 
space with human dimensions.

Most tools will have a 'zero' button that allows you to 'normalize' 
the human and its parts into a single coordinate system. Much more 
simple for playback.

The deeper you get then the closer you get to 'hand-coding' the stuff. 
In the major tool, and in any X3D editor, you can look at the data at 
each keyframe and type in some values. So, depending upon what you 
like, you can use the tool to hand-edit animations. Also, I think you 
will find that whatever the project, the most complex ones will always 
need to read and fix the user code. In X3D, you are reading the X3D 
names and data and in any other tool you are reading their special 
form. THe best tools will give you the best rendition of their 
functioning user code. Either way, the significant advances are made 
when the author gets in there and changes a couple of numbers of 
letters and manages to import and display the effect of that 
hand-coding step.

Finally ... if you have a problem, ask here and maybe somebody can 
help with specifics.

All Best,
Joe





----- Original Message ----- 
From: "John Richardson" <richards at spawar.navy.mil>
To: "'X3D Graphics public mailing list'" <x3d-public at web3d.org>
Sent: Thursday, February 25, 2016 2:42 PM
Subject: Re: [x3d-public] Non-Hand Coding of X3D


> Hello,
>
> In XML format
>
> <DO NOT MESS WITH THIS DEFINITION
> the definition of non-hand coded is....:-)   [in this space time 
> continuum. I make no attempt to define non-hand coded in parallel 
> universes]
>
> Use tool N(1) of M major modeling and animation tools [Maya, 
> Lightwave, Houdini, Cinema 4d, Poser, Daz Studio, GIS type tools, 
> Blender, COMSOL, ANSYS, Solidworks, BIM tools, Simulink, Mathematica 
> System Modeler, Maple's tools, Form-Z, Nemetchek's stuff, AutoCAD, 
> ProEngineer, plus any I left out that have reasonable market shares 
> or throw in open source stuff].
> Make unbelievably complex models with really sophisticated 
> simulations [behaviors in the common tongue]
> Select VRML or X3D for export format [see fbx below]
> Push the export Button
> Go get a cup of coffee or tea [no comment on whether you will 
> survive this step]
> Return to your Ergometric furniture [or stand to give your back a 
> rest]
> View the massively complex interactive simulation [business or 
> training or...] in the Instant Reality / Bitmanagement / FreWRL 
> viewer / X3D Edit / Simulink 3D animation / <insert view name here>
> Subnote: format conversion is not allowed unless you want to pull 
> out your hair (see following comment). This just makes the M number 
> of tool designers lazy and X3D authoring tool designers pull out 
> their hair...:-)
> If the viewer squeals or pukes or upchucks or throws up trying to 
> view the massively complex VR scene, execute X3D Edit or 
> Bitmanagement or Simulinks 3D animation tool or Mathematica or Maple 
> or COMSOL or....
> Press the import button
> Tweak to your hearts content
> Push the export button on the VRML/X3D/VR authoring tool
> View the massively complex interactive simulation [business or 
> training or...] in the Instant Reality / Bitmanagement / FreWRL / 
> X3D Edit / Simulink 3D animation / <insert view name here>
> Repeat tweaking until your viewer of choice or preferably every 
> viewer in existence is error free with regard to your VR scene
>
> Repeat the above process for modeling and animation tool N(2) 
> through N(M)....:-)
>
> Keep on repeating until a suite of massively complex simulations 
> generate error free viewing....:-)
>
> Publish the proclamation that VRML and X3D is not suitable for 
> non-hand coding development....:-)
>
> Note: M = 20 plus V where V is the number of tools the community 
> thinks are major or makes community participants smile while they 
> consume coffee or tea.
>
> Note: Export to fbx translates into "when facebook finishes spending 
> money on 3D VR" then fbx/facebook authoring tools will be the tweak 
> tools for facebook VR. Just to add an American obsolete silver 3 
> cent opinion to an earlier thread...:-).
>
> Final Note: Process should be turnkey on Windows PC, Macintosh, 
> Linux, mobile .... with community agreed upon minimum RAM, 
> processor, disk specs.
> /DO NOT MESS WITH THIS DEFINITION>
>
> Feel free to engage in vigorous architectural design of the X3D spec 
> to facilitate this definition. The X3D community will prevail...!
>
> John
>
> -----Original Message-----
> From: x3d-public [mailto:x3d-public-bounces at web3d.org] On Behalf Of 
> Leonard Daly
> Sent: Wednesday, February 24, 2016 6:02 PM
> To: John Carlson
> Cc: X3D Graphics public mailing list
> Subject: Re: [x3d-public] Non-Hand Coding of X3D
>
> 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/
>
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>