[kami]

it works faster (I think) and the real scale still works.
But one problem:
Each Tick on the timeline should be 10 frames in my case...
so I would need to be able to jump 0.1 ticks, which is not possible I think

edit: okay, I changed the timeline from 100 to 1000 and moved every keyframe to a 10 times higher number seems to be possible though.
But you're not very flexible with the speed of the scene anymore then.

[JDHill]

Yes, I've installed Bongo 2 and have been looking at it. It seems there is no manual, and though they have some information in the "Getting Started" tab of their website, I have found nothing describing the function of commands. The one you're using (BongoSetCurrentTick) sure looks like the right one, but you're right, it only takes integers. So it looks like stretching the timeline is the only way...if you're a Bongo user, I guess something like BongoSetCurrentPosition, taking a decimal number, would be a command for their wish list.

That said, now that I see how this version works, I'll just say: you really cannot use it (via BongoRenderAnimation, I mean). Nothing is going to work right, because the plugin does not know what's happening when you do.

[JDHill]

And here is a bit more comprehensive script:

Code: Select all

_NoEcho
_-RunScript (
  first = Rhino.GetInteger("Enter the first frame", 0, 0)
  If Not IsNull(first) Then
    last = Rhino.GetInteger("Enter the last frame", first, 0)
    If Not IsNull(last) Then
      increment = 1
      If first > last Then increment = -1
      Rhino.Print "Rendering frames " & first & " - " & last
      Rhino.Command "_Maxwell_BeginAnimation", False
      For frame = first To last Step increment
        Rhino.Print "Maxwell: Exporting frame " & frame
        Rhino.Command "_BongoSetCurrentTick " & frame, False
       'Rhino.Command "_Maxwell_RestoreViewport", False
        Rhino.Command "_Maxwell_RenderToMxs", False
        Rhino.Command "_ClearUndo", False
      Next
      Rhino.Command "_Maxwell_EndAnimation", False
    End If
  End If
)

Basically, it asks you to specify the first and last frame, either of which can be greater than the other, and then exports and renders those frames. I do notice some issues with materials disappearing from the viewport when animating the document, though opposite to what you report, it was simple color materials that did so, and it actually stopped happening after I assigned realscale textures to them. If it is a problem for you, you might try un-commenting the call to Rhino.Command "_Maxwell_RestoreViewport", False just before the Rhino.Command "_Maxwell_RenderToMxs", False call. That could be a little expensive, though, so if you think you need it, make sure to try it out on just a few frames first.

[kami]

The script is working fine for me and I was able to render a big part of the first animation. But it still took 15h to export all the frames, but that is manageable as it is still lower as the render times (36h).
I just wrote you a mail with another problem I'm having. I'll post it here in case anybody else is also reading this thread ...

Hi Jeremy

I got another issue with a file (Tower 1 full block) and am not sure what to do best.

The attached scene will be part of the animation. I created it two weeks ago. And I did some tests with it back then.
I wrote my export times down back then for the
- export with instances = 4 sec
- export without instances = 53 sec (but rendered twice as fast)
- exploded all the instances before and joined all the meshes per material (because much faster in the viewport) = 53 sec

Now the strange thing is, when I open the same file not I have these export times:
- export with blocks but no instaces = 2:26 min
- export the exploded blocks and joined meshes = 11 min

Would that even be possible?
It had around 9 mio polygons back then and still has that amount. I did not update the embedded bock (attached = PET simple.3dm).
The only thing that changed was that I updated to the latest rhino plugin and maybe my rhino if there was a SR update. But on another computer which still has an older plugin, it also takes the longer amount.
This is little bit strange and I don't know if I did something wrong or if that is possible?
Could the new MXS reference help me avoid this problem, as the object shown does not need to be changed in the animation.

Thanks
Christoph

[polynurb]

But it still took 15h to export all the frames

if you will be doing animations with moving objects more often, i would strongly suggest to ask your company to get an animation package that natively supports MX references for animations.

i had a collaborative project just recently, and the other guys were on max.

the workflow is amazing with the referencing!

we imported the very heavy scene (3000 trees,2000 people etc...) coming from rhino to max via mx ref.

in max we only animated the cameras, and did test renders.

NOW, when you export a frame, all that is written is a 7kb file, basically containing relevant sky settings and camera position. the scene is loadad at rendertime.

to export 2000 frames took maybe 30 seconds!!

so IF you have animated objects as well, you should put these on a separate "mxs layer" and again reference this mxs sequence in the 3d package, again the final mxs written will only contain the path to the ref-mxs needed for that frame, not the geometry itself.

like that you will be able to cut down export times to an absolute minimum.

[JDHill]

I don't see much problem with the file. Using instances, it exports in 4.04 seconds (SelBlockInstance, on the other hand, takes over a minute and a half to complete). Exploded, you have nearly 15K individual objects, and joined, you have one, which is nearly 5.5 million polys. This is just a huge amount of geometry. MXS References are good here, though, from an export standpoint: explode and join the objects, export one MXS, delete the joined objects, and replace them with a reference to the MXS. Export time for each frame will become instantaneous, but voxelization for each frame will be that required for any 5.5 million poly object.

[kami]

We are thinking about getting a software that is more powerful with animations at some point ... maybe when we have more animation jobs coming Also because rhino has a lot of problems when it comes to displaying a lot of geometry. But I really like the software and the work of McNeel!
But shouldn't the mxs reference work exactly like this in the latest plugin release? I already did a test and so far it works splendid. I also thought of referencing the whole non-moving parts as mxs references and only keeping the few moving elements which are pretty simple. How does it work with the path in the referenced mxs? And how does it work fine with the network render (I'm already having a lot of issues with this one because he keeps interrupting without any reason)?
I'll give it a few tries!

[kami]

one more question concerning the mxs references:
I could use instances in the referenced mxs file, so all the referenced mxs will smaller and voxelize faster, but the rendertimes are slower then, right?

[JDHill]

I already did a test and so far it works splendid. I also thought of referencing the whole non-moving parts as mxs references and only keeping the few moving elements which are pretty simple.

Yes, this is one of the primary use cases -- or even, a scene consisting of only MXS references, and a camera. It only depends on what you are trying to do.

How does it work with the path in the referenced mxs?

Not sure if this is what you mean, but during export, the plugin (recursively) reads referenced MXS files, in order to gather files for Pack & Go, if you have that enabled. Of course, you are only referencing the MXS, so it cannot alter any paths referenced therein (it can only read them and copy the files), so it is ultimately up to you to make sure it can work.

And how does it work fine with the network render (I'm already having a lot of issues with this one because he keeps interrupting without any reason)?

I personally have no specific knowledge regarding this.

I could use instances in the referenced mxs file, so all the referenced mxs will smaller and voxelize faster, but the rendertimes are slower then, right?

There is nothing specific to MXS references here -- if instances were slower when rendering the referenced MXS directly, then they would also be slower when rendering a reference of that MXS. If voxelization takes x-amount of time for the MXS, it will take the same amount when you reference that MXS. The main gains to be had are a) export speed, b) content control (meaning, an MXS is basically a "frozen" component, which cannot be changed accidentally), and c) the ability to instance references of MXS files, in order to render geometry (at whatever speed) that would otherwise be realistically impossible to render.

[polynurb]

Jeremy was faster than me, of course
i"ll still leave as is..





i haven't upgraded to the latest plugIn yet (just on my laptop) and haven't used mxs ref there.

but what i don't think is possible, as rhino natively has no timeline, loading mxs sequences won't be possible (eg.referencing moving objects on export)
*

how is the viewport speed with mxrefs?

i had trouble displaying the many trees as standard blocks, although i found a workaround if the geometry is mesh based:

make a display mode which doesn't shade but hides mesh wireframe and only show edges or even just naked edges, and assign it to the blocks.
the behavior with blocks and setobjectdisplaymode is somewhat non-linear, but it works.
*
concerning the paths.. nothing really to worry about, not more than usually

for an animation though, id go the pack and go way, moving all dependencies to a shared Network drive, that i smapped to all nodes.

i do never use send dependencies, it makes my network freak out.
but with the mapped drives it is usually more stable, but also for me not 100%.
sometimes it does like 600 frames and then manager will be stalled (the 100% cpu on one core thing)
sometimes it runs fine for days.

*

and yes instances are fine in an mx ref. that is what we did in our scene. all trees,cars,people were instances inside an mxref. rendertimes.. well instances that have intersecting ,alpha mapped leaves being motion blurred right in front of the camera won't be desirable, but generally i found the impact negligible, concerning the only other possibility would have been to export billions of triangles.

[JDHill]

You are correct on your assumption regarding MXS sequences, since there is no concept of that here. And viewport speed is pretty good, because references are only represented either as point clouds (using a percentage of vertexes per object), or as wireframe or NURBS bounding boxes (you may want one or the other depending on your display), which are culled to eliminate boxes contained entirely within other boxes.

[polynurb]

thanks for the infos.good to know

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

[kami]

The mxs reference thing really seems to be quite handy. Too bad I didn't think of it before ...

The viewport speed is excellent with the point cloud. But how could you change the display setting for it?

Since all my files are all on a network path and mapped with the same drives, I shouldn't have problems with that. So I'll usually disable or skip the dependencies. But I'm having the same issue as you explain. Sometimes it works fine for a few days, sometimes it crashes (manager closed), or just stalls or gives weird error messages ("is not an xml message"). I hope that will one day be fixed as it needs a lot of extra time and care. I installed teamviewer to make my computer accessible from home for checking and relaunching if urgent.

The thing with instances and maxwell is, that when having a lot of objects as instances, the export and voxel speed is much faster, but the render times are slower compared to just the objects. I'll try out which one gives the best ratio for my use.

My question concerning the network manager would have been, if the referenced mxs is part of the exported mxs, but I guess it is not, which makes much more sense.

[JDHill]

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.

[JDHill]

The viewport speed is excellent with the point cloud. But how could you change the display setting for it?

In Object Properties > Maxwell, there is a "Proxy Detail" setting.