[JDHill]

I should also mention, since we are talking about the display, an MXS ref is just a block instance in Rhino. You can easily use BlockEdit to change its definition to hold whatever geometry you want -- just don't mess with Obj Props > Maxwell for the reference later, or the plugin will undo whatever you did, replacing it with a new point cloud or wireframe/NURBS representation.

[polynurb]

i am just on standby with updating due to the custom mapping issue found in the latest rhino service (pre)release.

I am not sure what you are referring to -- a problem with Rhino, or the plugin. I got one report, and a file, from EADC, but that was a corner case, which was only due to some additional strictness in the 2.7.25 UV export. If you are using Maxwell materials, with explicit mappings and matching texture Channel values, that would not be a problem. If you have a concrete example of something working incorrectly, I would like to see it, so I can fix it before I do a public release of this build.

ok thanks, i was indeed refering to this:

http://www.maxwellrender.com/forum/view ... 3&start=15

as it seemed another user had problems with it and i do have files using this projection method i was waiting to see how things turn out.

custom mappings have given me a bit of trouble before (because of how rhino handles them) and i wouldn't wonder if they behave strange/different in the new SR.

by saying that i do not mean there is/was anything wrong with how the plugIN deals with them

[JDHill]

Thanks, that makes sense, I just wanted to know if you had a specific scenario.

[kami]

polynurb, were your experiences with rendering the mxs references all good? how big where your referenced mxs files?
I'm doing my first tests now and have 5 mxs references in my file, all together they have a size of 60 MB. The export is very fast now (10s) and so is the voxelizing (<10s) even though the mxs contains a lot of instances. But the loading of the instances took over 7 minutes, which feels a bit too high for 60 MB of mxs. Every of those mxs itself starts in a few seconds if you load it alone.
I am now trying to render the same scene without any instances in the references but then the mxs files are 387 MB totally and it is trying to load them since almost one hour now ...

[polynurb]

hmm.. that is hard to say.. it will depend on many factors, but it almost sounds like some file loading latency.

where exactly do you mean "loading" ? after the render window opens locally, or when a node starts a job?

1st i would try to gather all files locally and render one final frame locally, to see if you have a problem with the network latency.

i had maybe 6 different trees (25k-90k/~3000pcs) 25 different people (lo poly~2000pcs) and maybe 10 trucks/cars (5k-15k/~50pcs) that were all instances within a 160MB master mXref.

from the moment the job starts, meaning all files are then already loaded on the node/the computer that renders, it took about 30-45 sec for voxelization.

the loading of the single mXref file was very fast, not faster or slower than any other dependencie.

[kami]

hmm. I did put all the mxs on my local SDD (5 files - 60 MB) and it also took 4 minutes then to load it, which is too long. Every single scene opened in a few seconds.
With loading I mean, he checks the dependencies, then "Loading Bitmap & Preprocessing Data", then "Loading the MXS reference" ... which takes the several minutes.

I did one last test, where I would copy all my 5 files into one scene and exported it. (1 file - 60 MB). When I just render this scene it takes 5-10 seconds to open and voxelizes immediately.
But when I use it as a referenced MXS in and otherwise empty scene, he waits for over 6 minutes on the "Loading the MXS reference". This time the file came from my HDD, so the times should remain the same.

As this seems to be a maxwell, not plugin related issue, I'll report it to the support of nextlimit.

[JDHill]

I would do a comparison between that scene, and a version of it which uses no textures or other referenced files. If network paths are used, Windows can take quite a long time just telling code whether files exist or not.

[polynurb]

yep, i basically meant pack n go everything to your local hd, not just the mxs, and try from there.

i guess, while loading the mxRef, there will also be additional maps etc. loaded because before loading the mXref, he won't know he needs them.

[kami]

hmm, that is an idea. If I do the override materials while exporting the mxs it should do that, right?

[JDHill]

I don't think so -- that will make it render without the textures, but looks like (from observing the Maxwell Render Console panel) it still validates paths referenced in the scene before rendering.

[kami]

Ok. I removed the textures from all the materials in file that will be serving as a reference and it now renders like this:

Code: Select all

[03/April/2013 17:38:56] Reading MXS:D:\TESTRENDER\Tower ALL mid block no textures_x01c_0018.mxs 
[03/April/2013 17:39:34] MXS file read successfully 
[03/April/2013 17:39:34] Checking scene dependencies.. 
[03/April/2013 17:39:34] Checking Data 
[03/April/2013 17:39:34] Loading Bitmaps & Preprocessing Data 
[03/April/2013 17:39:35] Starting voxelization. 

Scene Info: 
Image output: D:\TESTRENDER\Tower ALL mid block no textures_x01c_0018.jpg 
MXI output: D:\TESTRENDER\Tower ALL mid block no textures_x01c_0018.mxi 

Geometry: 
- Num Meshes: 1980 
- Num Triangles: 30750 
- Num Vertexes: 19881 
- Num Normals: 12187 
- Num Materials: 12 

Camera: x01c 

Render settings: 

- Engine version : 2.7.20.0 
- Using RS1 engine 
- Desired rendering time : 9999 
- Desired sampling level : 25.000000 
- Using 24 threads 
- Multilight type: Disabled 
- Save lights in separate files:No 
- Motion blur: enabled 
- Displacement: enabled 
- Dispersion: enabled 
- Illumination layers: 
. . direct layer: true 
. . indirect layer: true 
. . direct caustic reflection layer: true 
. . direct caustic refraction layer: true 
. . indirect caustic reflection layer: true 
. . indirect caustic refraction layer: true 

[03/April/2013 17:39:35] Start Voxelization 
[03/April/2013 17:39:35] End Voxelization 
[03/April/2013 17:39:35] Voxelization done. 
[03/April/2013 17:39:35] Start Rendering 

And when I load it into a new, empty scene as a mxs reference it renders like this:

Code: Select all

[03/April/2013 17:33:07] Reading MXS:D:\TESTRENDER\untitled_Perspective_0017.mxs 
[03/April/2013 17:33:07] MXS file read successfully 
[03/April/2013 17:33:07] Checking scene dependencies.. 
[03/April/2013 17:33:39] Dependency found: D:\TESTRENDER\Tower ALL mid block no textures_x01c.mxs 
[03/April/2013 17:33:39] Checking Data 
[03/April/2013 17:33:39] Loading Bitmaps & Preprocessing Data 
[03/April/2013 17:33:39] Loading MXS references... 
[03/April/2013 17:42:00] MXS references loaded successfully 
[03/April/2013 17:42:00] Starting voxelization. 

Scene Info: 
Image output: D:\TESTRENDER\untitled_Perspective_0017.jpg 
MXI output: D:\TESTRENDER\untitled_Perspective_0017.mxi 

Geometry: 
- Num Meshes: 1983 
- Num Triangles: 30750 
- Num Vertexes: 19881 
- Num Normals: 12187 
- Num Materials: 12 

Camera: Perspective 

Render settings: 

- Engine version : 2.7.20.0 
- Using RS1 engine 
- Desired rendering time : 9999 
- Desired sampling level : 25.000000 
- Using 24 threads 
- Multilight type: Disabled 
- Save lights in separate files:No 
- Motion blur: enabled 
- Displacement: enabled 
- Dispersion: enabled 
- Illumination layers: 
. . direct layer: true 
. . indirect layer: true 
. . direct caustic reflection layer: true 
. . direct caustic refraction layer: true 
. . indirect caustic reflection layer: true 
. . indirect caustic refraction layer: true 

[03/April/2013 17:42:00] Start Voxelization 
[03/April/2013 17:42:02] End Voxelization 
[03/April/2013 17:42:02] Voxelization done. 
[03/April/2013 17:42:03] Start Rendering 

It takes over 8 minutes to load the (60MB still) MXS.
For me this cannot be a path or latency issue. And I have no idea what is happening ... I already posted a report on the maxwell support.
If you want to play around with the scene: https://dl.dropbox.com/u/4900894/Tower% ... xtures.zip
It is my starting scene, where I got all my objects as rhino blocks and export them as an mxs with instaces on.

The last remaining thing I can do is to replace all the rhino blocks by mxs references. Then I'll have a lot of mxs references in my rhino file, but he only has to load 5 mxs. But I think then rhino will take ages to export again.

[JDHill]

For me this cannot be a path or latency issue.

I was not saying it was, but only that we had no way of knowing without checking. Regarding your file, you are creating an MXS with around 150K instances. I am going to say that the extra time is likely being taken in making sure that everything in the file gets a unique name when loading the MXS reference. When you render the MXS itself, uniqueness is guaranteed, otherwise the file could not have been written, that is why it is instantaneous in that case.

What I recommended was exploding blocks, joining them into one mesh, exporting that mesh to an MXS, and then replacing what was exploded with a reference to the MXS. You have all these stacks of objects, 8 wide, 2 deep, and something like 20 high -- I'd start by exploding and joining one of those groups, then inserting MXS references to replace groups like that throughout the model. The situation is not dissimilar to that of instances -- twenty million instances of a single blade of grass is worse than a single mesh containing twenty-million blades, since each instance will have a material, name, transformation, etc. It is necessary to use a reasonable balance.

[kami]

hmm. I started more or less from one large mesh object for every different tower. But then I have file sizes of almost 400 MB for the referenced mxs and I waited 4 hours before that loaded in the render engine. I was hoping that the instances would be powerfull enough to do that. I have 67k instances in the file.

My latest test results from two different tests:

1st
I replaced all the block instances with mxs references. I takes around two minutes for the export out of rhino then and renders very quickly. So far the best results I'v had. But the display in rhino is very slow then.

2nd
I tried rendering each tower seperately and inserted only one tower as a referenced mxs. Each file rendered very quickly then. Between 5 and 20 secs each. Added all together that would be 1 minute.
Now the same test with all 5 files as referenced and it took 5 minutes opposed to the one minute it should have taken from my understanding. Could there be that at some point there is a critical amount of objects reached?

What you suggested would be a mix of instances and joined mesh? For example joining one row and then instancing all the rows. I could do that next test, but I will lose the randomised modifications and variablity I added to the objects by slightly rotating/moving them.
For me it is hard to understand that the same mxs renders very fast on its own, but takes several minutes to load when used as a referenced mxs...

[JDHill]

hmm. I started more or less from one large mesh object for every different tower. But then I have file sizes of almost 400 MB for the referenced mxs and I waited 4 hours before that loaded in the render engine.

Working from the files you originally sent, using one tower exploded, joined, and exported to MXS (it needed almost 8GB and several minutes to do the export and produced a 186MB MXS), referencing the resulting MXS in a new document, and then rendering in Maxwell, it takes 3s to load the MXS reference, and 35s to do the voxelization. I do not see, in this case, how you would get to 4 hours, unless a) you had forgotten to remove the instances after explode/join/export/reference in one of the files, or b) the total size of the geometry in the referenced MXS files is large enough that you run out of physical memory and start paging to disk.

1st - I replaced all the block instances with mxs references. I takes around two minutes for the export out of rhino then and renders very quickly. So far the best results I'v had. But the display in rhino is very slow then.

I suppose it may be slow with thousands of instances of anything, even if they just contain a small point cloud. The export should not be substantially slower than with other instances, but somewhat, because there is more work to do per instance of MXS reference.

2nd - I tried rendering each tower seperately and inserted only one tower as a referenced mxs. Each file rendered very quickly then. Between 5 and 20 secs each. Added all together that would be 1 minute. Now the same test with all 5 files as referenced and it took 5 minutes opposed to the one minute it should have taken from my understanding. Could there be that at some point there is a critical amount of objects reached?

Not all operations are linear, some take increasingly longer the more data needs to be processed.

For me it is hard to understand that the same mxs renders very fast on its own, but takes several minutes to load when used as a referenced mxs...

You say you contacted the techdesk, and maybe they will have a different reason, but like I wrote above, in the case where the referenced MXS contains thousands of entities, I would guess it to be due to the need for making names unique as the referenced MXS is loaded.

[kami]

I do not see, in this case, how you would get to 4 hours, unless a) you had forgotten to remove the instances after explode/join/export/reference in one of the files, or b) the total size of the geometry in the referenced MXS files is large enough that you run out of physical memory and start paging to disk.

a) don't know if that can be the case, as I exploded them before joining. so they were gone and I don't think it is b) as I have 64 GB of RAM. But I can double check with the task manager. I didn't see how fast just one file was, as I had all the 5 towers as individual files referenced. All together they had around that 400 MB and I only tested loading all of that 5 files at once which ended up with that 4h. ... But your 3s sound like exactly what I want... If I find the time tomorrow, I'll redo the experiment and also try your exact procedure.

My latest test finally showed a somehow successfull compromise. I exploded all the towers with the easy geometry objects (all towers except the bottle tower) and joined the meshes. I left the bottles as block instances and exported them like that. This seems to be the best compromise between number of objects and size of the file/geometry.
The exported mxs took around one minute to open when being referenced and I think that this is a reasonable time.

Pardon me, if I am becoming frustrated after one week of testing and error hunting. I thought maxwell was pretty strong concerning heavy geometry and a lot of instaces, and test scenes showed a lot of much more complex objects (http://support.nextlimit.com/display/ma ... /Instances). The weird thing is, it really works as expected when not being referenced, but then rhino is the bottle neck as it has problems with lots of objects, even if they are instances or blocks. (The mxs references are a bit faster than the block instances though, in display and in exporting)