Export to WebGL?

jgorder_ed5e1858cf

How can I take a rich scene or animation and export to WebGL?

Thanks,

Dream Cutter

Hi I know of several good methods, however it takes some work to prepare DAZ figures and props for export so be prepared to use several packages to make the 3d pipeline to HTML work out.

The best 3d HTML publishing and rendering packages are....

1. For Game and interactive HTML5 WebGL I recommend Coppercube 4 by Ambeira. I have a tutorial and some threads in the FarmPeeps.com forum that explains what is needed and how to turn your 3d into a game. Coppercube is a complete 3d publishing package with 3d output to .exe (fastest), Flash 11, HTML5/WebGL and best of all... ANDROID! Imports .x and .b3d animated mesh, obj static. Has some UV tweaking and dynamic lighting effects. Coppercube has rudimentary in world physics. No programming required. Supports animations baked into fbx and converted to .x or b3d.

2. For static and interactive demonstrations I recommend SimLab 3D which imports .obj, and .fbx directly and output is 2D tiff with ALPHA TRANS, JPG, PNG, and Video. 3D ids HTML5, 3D PDF (cool!) , and Android /Apple viewer. SimLab also has a fantastic rendering engine based on Luxion. Real and super high res and lighting, and a killer material selection in the paintbox. Has good surface tools with UV and Materials. Outputs OBJ as GROUPED by MAT or orig structure. Can't pose using IK. Good keyframe animation - but it is designed for simulations and scene rather than games. WIll not import RIGGED animations - IE NO bhv.

FirePro9

Just curious if the above recommendations for export to WebGL are different today, a few years later?

I've looked at Coppercube and Playcanvas and could get by with them if necessary. Hoping not to have to learn Unity.

Richard Haseltine

I believe that WebGL - which as I understand it passes 3D data from a server to browsers viewing the site - would not be permitted under the Daz EULA.

Dream Cutter

Richard Haseltine said:

I believe that WebGL - which as I understand it passes 3D data from a server to browsers viewing the site - would not be permitted under the Daz EULA

Yes, I agree fully.  In practice I have a DAZ commercial game publisher license to support my 3d scene publishing activity and I never include original mesh or textures in the webgl publications.  For practical purposes a typical scene with 3 web gl biped figures, each must be around 33K polys max and all texture ram in a scene is limited to 64MB and approx 128mp polys (it will crawl, 1/4 is optimal).  It takes atlas and small testure maps and severe decimation to accomplish this. This certainly obfiscates the product way more than any encryptiuon in a tradditional software game as afforded by high density data didstribution methods.  

Tips:

Another neat technique is to render out alpha filtered figures as posed images or otion animation as short image sequences and and project them to the sides of a cube within a webgl scene.  Using this method, you are within standard rights and also can create enormously dense crowd scenes & game backgrounds.  USing scripting the images can be toggled and animation sequenced swapped.

FirePro9

Would the same be true for 3D PDFs?

Dream Cutter

FirePro9 said:

Would the same be true for 3D PDFs?

Not sure what concept you are referring to however if its the standard DAZ content product license user restrictions, you are not permitted to distribute the purchased product to unlicensed users even if its for non-ncommercial purposes.  You are unrestricted in the ability to publish value-add 2D renders of the geometry and textures, in other words originally created scenes of constructed from DAZ products and rendered 2d images is the copyright of the artist and therefore not further restricted in use.  You cannot distribute, sell or publish original source content in any product iparticullary but not limited to source geometry and texture bitmap data in any form. To accomidate 3d game publishers, DAZ store does sell "game license" upgardes for DAZ Original Product (as do a limited number of PA's) that increase flexibility in he publication or distribution of geometry data. Any game licensed source data must either be protected so that the original product cannot be extracted or reproduced in the publication. My way to accomplish this is to avoid putting source data in the published project at all.  The exact use terms are well documented in the EULA and Game License product desciptions.

So considering 3D-PDF's use a standard 3d format (U3D) that is easily convertable to obj.  Its very similar to WebGL, even with PDF documents proctecd  by passwords  and encryption levels, producers cannot isolate the underlying geometry and textures from the 3d PDF viewer interface. exposing the content.  So same restriction with WebGL applies, applies must not include any unproperly licensed, not can licensed content be included that can be used to recreate the original or a near approximate of the original that could considered by the license holder a violation. These are great questions on a confusing topic, worthy to explore because this understanding fundamentally affects the core value of your DAZ library. So to be comfortably safe that user terms are being met,  plan all published media development to stick well within the bounds of the spirit of the agreement by not even giving the appearance improper use.

aspiringartist

What do you think about making FBX viewer (online/website) for local viewing, without sharing abilities, that uses HTML5 fileReader facility and so does not passes the fbx/3d data to the server? Would that be within EULA terms? It probably would be not much different from desktop fbx viewers, but is exporting and viewing fbx for personal use (like in VR) allowed?

I've recently created simple local WebGL fbx viewer.