complete Changes for Blender exporters

[JCPalmer]

I think I have enough to do a small update to the Blender exporters.  Am thinking about dropping a couple of kind of obsolete features.  Both of these are used in the very "involved" loop of reading a meshes geometry.  Pulling these out would simplify this area.  They are gone for sure in the source code generator, but input with regard to the JSON generator would be good.

1. Remove the checking for, and splitting up of meshes with more than 64k vertices.  This seems like an option which is becoming irrelevant.  The code complexity involved actually spills into the caller too.
2. Flat shading both for the mesh and the entire scene.  It seems this can be replaced with SplitEdges modifier.  This causes exports of fewer vertices.  It is documented.  Using as many features that Blender already has sounds advisable.

As far as new stuff:

• Separate scene level control of # of decimals of scalable (positions)  & non-scalable(everything else) geometry.  Currently 4 decimals for all, but do you really need 4 decimals if your model is scaled in inches (micro-inches)?  Hundredths of inches are probably not even going to be visible with an extremely close camera. 9999 possibilities in each dimension for a normal seems like overkill.  My calculation blew out with 9999³.  Default for each would still be 4.
• ES3 / ES6 switch for source code generation.
• Better checking for un-applied transforms when using an armature.

Thoughts?

 

[Guest]

1. Can't agree more. We now have 32 bits indices everywhere

2. Ok!

All good for all changes

Thanks a lot for taking care of that. It saves me so much time

[JCPalmer]

As per my test of using ES6 classes which are sub-classes ES3 simulations of classes.  It is safe to just change to ES6 without a switch for ES3.

[V!nc3r]

May I suggest an option to add? Be able to disable automatic baking!

• on Blender Render: on huge scene, you just have to make a mistake and assign on the same materials two textures sharing the same influence, and you're ready to overflow your CPU and try to kill Blender process.
• on Cycles: if no automatic baking, then how to "translate" the materials? I think this could be a great feature to using Cycles as a PBR exporter instead of Standard, and to "force" the user to use the Principled BSDF shader for that (in the same way of GLTF exporter, but by using directly the default Cycles shader)

It seems that for the Blender Render part this could be done without difficulties? But maybe my suggestion for Cycles lead to a huge code rewrite

[babbleon]

I'd definitely benefit from being able to disable automatic baking when in Cycles.

4 decimal places enables me to model things to 0.1 millimetres (I model in metres).. anything less than 4 decimal places would be a problem.

[JCPalmer]

On precision, it is going to be even more flexible, not just positions & others.  The values will range from 1 to 5 (0 to 5 for positions).  As before, this is the max value, trailing 0's are removed.  In ToB, even leading 0's are removed (JSON does not allow this).  Here is UI for ToB (with defaults set).  JSON exporter will be similar.  This part is implemented & in debug.

As far as not baking, I will look into shutting off, and exporting without material.  You could then hand write any material on the BJS side.  Kind of doubt there will be time to add PBR via cycles.  I need to move on by next week.  If you post an example .blend & maybe what , I will at least load it.  I do not have 4 days just to study what to do.  I screen capture of Blender UI mapping to BJS values would definitely help as well.

[V!nc3r]

If you want, here a scene using Principled Cycles shader: https://github.com/Vinc3r/cornellBox/tree/master/3D (cornellBox-Cycles.blend)

I don't know if you have already play with nodes and python, as for me not too much but maybe this snippet can help you.

As for exporting without material I don't think this will be convienient. At least having a default PBRMaterial with default options but named as in the 3D scene could be a nice step

As for the expecting result, it can probably tend to this playground.

[edit] of course you need last version of Blender (2.79) to get Principled sharder

 

Edited February 23, 2018 by V!nc3r

[JCPalmer]

@V!nc3r,  5.6 is commited.  I did not touch materials.  With Blender 2.80, I have the feeling materials are going to need a lot of changes.  Not going to do it twice.  Use the other exporter if PBR is needed, or code it on the BJS side.

[babbleon]

@JCPalmer & @V!nc3r - if you add this:

        write_string(file_handler, 'customType', 'BABYLON.PBRMaterial')

to this file (I put in between lines 325 & 326),  it exports all the materials as PBR albeit a basic ones (when using Blender Internal, not tried with Cycles).

This is a post more for my benefit than anyone else, but would be good to have a checkbox on the materials tab on Blender along the lines of 'Export as PBR (simple)'' so we can chose which are PBR and which not.

[JCPalmer]

On 3/2/2018 at 3:44 PM, babbleon said:

@JCPalmer & @V!nc3r - if you add this:

        write_string(file_handler, 'customType', 'BABYLON.PBRMaterial')

to this file (I put in between lines 325 & 326),  it exports all the materials as PBR albeit a basic ones (when using Blender Internal, not tried with Cycles).

This is a post more for my benefit than anyone else, but would be good to have a checkbox on the materials tab on Blender along the lines of 'Export as PBR (simple)'' so we can chose which are PBR and which not.

This solution is fine as a work around.  Think as a "supported" option, better to leave it as it is & let people add the line themselves.  I am not willing to do anymore work on the exporter until Blender 2.80 beta is out.  There is supposed to be a new render & lots of changes.  I also do not know what I'll do then, just that I am not going to waste my time now.

[V!nc3r]

Great! You're right about 2.8, a lot of changes is coming