[kami]

thanks, JD
The idea with .sky files is very good. I haven't thought of it before, but it almost suits perfectly my needs.

With the export: I didn't mean fire, but about exporting to mxcl. It wouldn't matter that much with fire.

[JDHill]

Thanks, I hadn't noticed that.

[kami]

Hi JD
Some of my custom material preview scenes do not work with the latest version.
I know you made them work the version before, but they don't anymore.
Thanks, kami

[JDHill]

Yes, it looks that way -- I don't think there's anything I can to about it this time, though.

[val_z]

thanks for new update.
speed, speed, speed. what took minutes - now exports .mxs in few second.

I got to check in folder for files - and there were 3 .mxs files (I though it was an error - I hit export for 3 times) - but it export so fast.

[kami]

Yes, it looks that way -- I don't think there's anything I can to about it this time, though.

that's very sad to hear. Is this a technical restriction? since some of them work, what makes the difference?

I think I found two bugs (in combination with mxcl, did not test fire):

1 - If you got a three-layered material with displacement and the two top layers are deactivated, then displacement does not work as well


2 - Could it be that the custom mesh settings are beeing ignored? I tried a displacement on an object, once with a meshed object, once with custom mesh on. both times the settings identically and they looked identically in the preview. It turned out completely different.

[JDHill]

For the first issue, I'll look into it as soon as I can (I'm out of town currently), but for the second, ignoring is not really possible -- we simply render whatever meshes we are given. I may recall instances of custom meshes not 'sticking' but I really couldn't tell you when that would've been, or what version was being used (i.e. it was a long time ago).

[kami]

Hi Jeremy

Thanks for looking into it, when you're back, it is not urgent

On the second issue, I did a test right now. Here are the results:
These are three identical objects with a displacement for showing the meshing effects. The left one without any mesh settings (just the standart from rhino). The one in the middle with custom mesh acitvated, settings as above. And the right one as meshed object with the same settings.

On the render: the one in the middle and the one on the right should look the same, since they got the same settings. but they don't! instead the one in the middle looks the same as the one without any custom mesh settings.

I could send you the scene if needed.

All rendered with mxcl, with Fire I get the strange message:
Maxwell: error: AccessViolationException @ CmaxwellRender::startRender() (caller=Maxwell.Scenes.nIPScene.RenderScene)

Thanks,
kami

[JDHill]

A test with simple planes appears to work fine here, using the 4 August WIP build. However, there is a post on the Rhino newsgroup saying that "In the Aug 4 beta the Mesh command is giving me the same mesh regardless of settings." So I suppose there could be some geometry-specific issue, but either way, as I indicated previously, the plugin can only export whatever mesh Rhino provides for any given object.

Regarding the Fire error, thanks for sending the model, I'll take a look.

[kami]

so it's a rhino5 problem? i'm working with 07-26 still

[JDHill]

All I can really tell you is this:

• 1. open your file
  2. set custom mesh settings on both objects (use different settings, just for the test)
  3. double-check that they have different meshes shown by the 'Preview' button
  4. run ExtractRenderMesh on the two objects

You should now have two mesh objects, neither of which uses the custom mesh settings set in steps 2 & 3. Next:

• 5. draw a plane (100 cm or so) and make a copy of it
  6. repeat steps 2 & 3 above with the two planes
  7. repeat step 4 above

Here, I get two custom-meshed planes, as expected. To confirm all of this, export the whole document (now with 4 planes) to Studio and switch your viewport to Hidden Line mode; you should confirm that the meshes for the planes are as expected, but that none of the meshes of your objects are meshed according to your custom parameters.

Regarding the Fire error, I have not been able to reproduce that. I do notice, however, that there seems to be some issue with the displacement, apparently having to do with the precision of the mesh, its distance from the origin, and the height and offset of the displacement -- in short, the object (the mesh object you included, not the NURBS ones, which are ignoring their custom mesh parameters) renders with odd some holes in it. I only see this with the current release engine (and in Studio 2.5.1 as well) though, and not with my current internal build, so I assume some work has been done in the engine which affects this.

[kami]

Here, I get two custom-meshed planes, as expected. To confirm all of this, export the whole document (now with 4 planes) to Studio and switch your viewport to Hidden Line mode; you should confirm that the meshes for the planes are as expected, but that none of the meshes of your objects are meshed according to your custom parameters.

So it looks like the objects I got are corrupted. Thats kind of a relief, because I could not understand why I didn't get displacement to work the way it usually does ...
But a bit strange as well, since I recieved these models as a .3dm , so they were modelled with rhino (i think).
Thanks for clearing this up!

[kami]

Hi JD
I think, I've found a bug: The original position of objects with motion blur is not saved, so if you close and reopen a file, the motion blur is lost. (rhino v5)
Cheers,
kAmi

[JDHill]

No, that's just the way it works; the plugin will temporarily store in memory, and use for motion blur calculation, a copy of your mesh, but it will not save that copy in the document. Technically, it would be possible to do so, but it probably would not be a good idea, since what it would be saving is a copy of the render mesh, which is very temporal in Rhino -- even within the session, the render mesh may be altered, making useless the in-memory mesh copy. In theory, this could change in V5, depending on whether the final implementation of the Gumball allows for getting two transformations for the object, rather than two copies of the transformed mesh.

[kami]

hmm. but how can you really use motion blur if you cannot save a condition?
has this always been like this? I think I've used it before, but maybe I'm wrong ...
would be really great if this will be possible in the future then!