Shape name parameter

[Lord Crc]

I've added a "name" parameter to all shapes. This is used when printing shape-related log messages, for aiding troubleshooting.

Here is some sample output from a scene with two named objects and an "anonymous" area light. Shapes without a name parameter gets assigned a name based on which number the shape is in the scene file, and the type. As you can see the area light is the 3rd shape.

Code: Select all

[2012-01-10 04:50:09 Info: 0] Shape 'Plane': Loading PLY mesh file: 'untitled/Scene/00001/Plane_0000_m000.ply'...
[2012-01-10 04:50:09 Info: 0] Shape 'Cube': Loading PLY mesh file: 'untitled/Scene/00001/Cube_0000_m000.ply'...
[2012-01-10 04:50:09 Info: 0] Shape 'Cube': Loading PLY mesh file: 'untitled/Scene/00001/Cube_0000_m001.ply'...
[2012-01-10 04:50:09 Debug: 0] Shape #3 (trianglemesh): Mesh: accel = none (global), triangles = 2 wald, quads = 0 quadrilateral
[2012-01-10 04:50:09 Debug: 0] Shape 'Plane': Mesh: accel = none (global), triangles = 2 wald, quads = 0 quadrilateral
[2012-01-10 04:50:09 Info: 0] Shape 'Cube': Applying 2 levels of loop subdivision to 10 triangles
[2012-01-10 04:50:09 Info: 0] Shape 'Cube': Subdivision complete, got 160 triangles
[2012-01-10 04:50:09 Debug: 0] Shape 'Cube': Mesh: accel = none (global), triangles = 160 wald, quads = 0 quadrilateral

For reference here's an example of one of the shapes

Code: Select all

Shape "plymesh"
   "string filename" ["untitled/Scene/00001/Cube_0000_m000.ply"]
   "bool generatetangents" ["false"]
   "string name" ["Cube"]


The core itself does not care what the name is, or if it's unique between shapes, as you can see above the Cube object is actually exported as two separate shapes as it has two materials assigned to it. For luxblend25 I felt it was most natural to use the object name for all shapes exported, but we can of course change that easily.

I must admit I haven't tested this with networking yet, but I think it should work as expected. Also I should add that luxblend will export the light name for the shapes, the above was just an example.

[pciccone]

Great idea. Thanks!

[SATtva]

Cool, thanks! Earlier it was a PITA to find an "inconsistent normals" mesh in a big scene.

[J the Ninja]

Whoa! That was quick! Nice work! And you did the luxblend support too!

One thing though...

For luxblend25 I felt it was most natural to use the object name for all shapes exported, but we can of course change that easily.

On the surface this seems to make sense, but it's not that simple. The object datablock (node, if you will) is only a container that holds some properties (like object transform, for example. There are a bunch more that are used within blender, but Lux doesn't need them). The main thing is, the object node (whose name we currently use) is not the mesh, it has no geometry of its own at all. The geometry is attached to the mesh node, which is selected over in the mesh panel. While a new mesh object by default will spawn a new mesh node with the same name, what mesh nodes are connected to what mesh-object nodes is arbitrary and can be changed at any time. Multiple meshes can be connected to a single object too.

The main argument I can see for using the object name is many users change their object names but do not change their mesh names (mainly since the object name is displayed in the viewport and outliner and the mesh name does not appear in either). So its not uncommon to find a whole bunch of neatly named objects all connected to meshes with names like "Cube.009".

Also, on the flip side, we name the PLY file for the mesh name, not the object (in this case its mandatory as a given file name and set of geometry have to match), so using the object name can give fun log messages like this:

Code: Select all

Shape 'foo': Loading PLY mesh file: 'untitled/Scene/00001/bar_0000_m000.ply'...

Another point, although I'm not sure if this is an argument for mesh names or object names : since object and mesh nodes must both have unique names, but the same mesh node can connect to multiple object nodes, it's quite possible to have a number of objects with different names sharing a single mesh. For example, the objects flame1, flame2, flame3, flame4, and flame5 are all sharing a single mesh named "flame". (note that in this case the mesh may be instanced, but this is not guaranteed)

[SATtva]

note that in this case the mesh may be instanced, but this is not guaranteed

In Blender you either have instanced meshes (in this case a single mesh name is referenced from multiple objects), or unique names -- you can't have several different meshes by the same name. Am i wrong?

As to the overall question, i'd say we should use mesh names (not object names) on export with LuxBlend. As Lux log mentions "shapes" and not objects, i think this is more logical. A user could easily find any relevant mesh and its parent object(s) in Outliner.

[Rhys]

note that in this case the mesh may be instanced, but this is not guaranteed

In Blender you either have instanced meshes (in this case a single mesh name is referenced from multiple objects), or unique names -- you can't have several different meshes by the same name. Am i wrong?

You can have different modifiers and things on different objects with the "same"(what you can see of it in the gui) mesh name. This may not be relevant though.

[SATtva]

Yes, indeed, i forgot about modifiers.

Is it possible with the current framework to export shape name as "Object:Mesh"? In this case user will have all the data he needs to find any problem.

[dougal2]

Yes, indeed, i forgot about modifiers.

Is it possible with the current framework to export shape name as "Object:Mesh"? In this case user will have all the data he needs to find any problem.

I'd think this is the best idea.

[Lord Crc]

Object:Mesh sound good. I must admit the whole datablock / object separation makes my head hurt and thats why I went for the easy option

[paco]

Nice work LordCrc