Planning changes for the Next Blender exporter release

Content creation (3dsMax, Maya, Blender, glTF)
#1

I am thinking about changes to the Blender exporter centering around generating more optimized objects before they are even loaded. Am using this for my planning guide, https://doc.babylonjs.com/how_to/optimizing_your_scene

Some of these features are scene wide, like freezing active meshes. Probably not going to do those. Those are best controlled with your own code.

Some I am already doing, like FreezeWorldMatrix, and probably will put in the CSV statistics output file, making it optional.

I do have questions about some others. First, I have a ‘check only once’ option for a material. It never did what I intended. Can you freeze a material, possibly before the texture has even arrived? If yes, can this be specified in the JSON file?

Next, do meshes without indices have to be converted, or can they just be created that way to begin with? If yes, I could do a custom property on a mesh by mesh basis, but think specifying a reuse threshold and let the system decide would be more powerful. Would be a little slower, since would have to generate the indexed version first in order to decide if the threshold was crossed, then maybe redo it again without the index, but so what.

1 Like
#2

I do not think you can freeze material by the json and you should be able to call it before it is ready as long as all its inputs have been sets.

Adding @bghgary and @syntheticmagus as they might be interested in the optim side of think cause I wonder if it should be part of the exporter or a special tool we could plug on any models.

1 Like
#3

Those options could all be turned off, right? In our code for instance there tends to be a ton of post-processing for imported files which means the optimizations would be additional overhead for us because we have to disable them again right away. Actually, we don’t even generate many materials in Blender, we just give them unique names and an identifiable color and then put in the proper material on the BJS side. For shader-based materials this is simply required, for instance.

Therefore, I second @sebavan’s comment that a special tool would perhaps do a better job. Maybe a general post-processing framework running as a node app where you can run all sorts of optimizations and put in your own callbacks using the Babylon API to swap materials etc.? Sorta like a SAX parser for Babylon files… I would use something like this in a heartbeat if it was available. That would allow people to do all the post-processing of babylon files during the build stage instead of at run/load time.

edit: Can you put shader code into babylon files?

How to correctly import modules in Typescript node headless environment
#4

Yes with ShaderMaterial (or NodeMaterial now as well)

2 Likes
#5

For the indexed vs un-indexed part, it is not so much making the switch, but knowing if it is actually going to help or not.

Was thinking about a scene tool, which would compare the vertex shader times each way, by loading a .babylon and capturing the GPU time for a number of frames each way. Here is a mock up so far.

Comparer
Comparer762×342 33.6 KB

The context is actually that black square. The reason it is so small is that way the fragment shader part of the time will be as small as possible. This test is really trying to get at the vertex shader time. Also, not going to draw right for meshes with textures anyway, unless they are embedded into .babylon.

To get that GPU time, I wanted to get the render time for each mesh. My thought was to force each mesh to be the only one drawn, and take the time from the same place the inspector gets is. Where is that?

Other precautions:

  • Add / Remove cameras. so there is only one.
  • All meshes need to have no children. Child meshes cannot be drawn alone.
  • Delete all instances

Any thoughts, and again where does inspector gets its GPU time data?

#6

Probably just making notes for myself, but there is an EngineInstrumentation class, where inspector must surely be getting its data from.

Do not know how to use that, well yet.

#7

Ok, I get 0 for my gpu time. See this is disabled everywhere, but FireFox, but need to enable flag gfx.webrender.debug.gpu-time-queries. How do you do that?

Edit:
Found it in about:config, but turning it on did not do anything. Just to verify my code was not right, I tried doc pg, https://www.babylonjs-playground.com/#HH8T00#1. It still reports 0’s. Waste of an afternoon.

#8

Not sure what the issue could be it is all working for me on Chrome Windows:

image

What browser OS did you try ?

#9

I agree FF looks broken at this point, maybe you could create a ticket on their bug tracker ?

#10

Thanks. My form is beginning to run using Chrome. I have not published it, and I am beginning to think that the idea that there is a performance difference between indexed & un-indexed is bunk. Do a test of a 100 runs each way of a 5895 / 16302 (verts / indices) mesh one time & get -4%, reload page & try it again results in 15% gain.

Also, tried to convertToUnIndexedMesh() a mesh with instances errors. I thought I had disposed of the instances, but had forgot. Will at least look into that some more.

Did not see where Firefox bugs are reported, from the browser itself, anyway.

1 Like