[polynurb]

Hello JD,

I have another riddle for you:

When I use HDRi with any offset applied to them, and I reopen the scene
they jump to "impossible" values.. actually 1,6 becomes 160 and 97 - 9700.
they also appear at a wrong location in the viewport (so it is not a real "multiplication" of the original value). when I delete the surplus Zeros/add commas it works fine again.




btw. sun location is working again in some files...

when I find the time (not for another 2 weeks) I will do a clean reinstall of Xp
as there are some strange things going on with my workstation.
(rightclick is an issue even outside rhino sometimes; simply crashes explorer)

cheers,

daniel

[JDHill]

Thanks Daniel, I've already found and fixed this one in the current build. The UI does a divide/multiply transform on the real values to make them 'friendlier', and though I don't remember changing anything in 1.6.1, apparently, I did. I think location works fine most of the time, it's just some specific cases where the calculation for gmt is not happening correctly when the file is read.

[Polyxo]

Hi Jeremy,
I enjoy the simple solution you found to make Motion Blur accessible for Rhino users! But I found some problems.

Copies of objects with Motion Blur should inherit all properties. Therefor for these new objects also Motion Blur is checked on the Maxwell Properties page. In fact however, only the source objects will show Motion Blur.

Now if I go ahead and uncheck MB for the copy and recheck it again, set a new MB start-position for the copy only, the original object loses its MB properties and only the copy shows up correcty.

How would I do the following in the most convinient way?

Set up MB for my little Heli (Top and Rear rotors) create some copies and move these copies around in the scene and also tilt them in all axis.
The end result would be a nice array of helicopters in different orientations. Now say the MB inheritment would work flawlessly. Wouldn't additional movement and rotation for the rotors get tracked while I distribute the Helis inside the scene? Resulting in a very wild MB solution?

I presently can not imagine solving this question without making this rotation a understandably "local" transformation around a fixed axis, which however may be moved around in space and rotated. This is where Bongo would have to come into play, no?

As a last remark:
MB properties are not getting saved with the file. As a first workaround for quickly putting everything back into place I found the Rhino command NamedPositions helpful.



The original object with MB on Top Rotor


A copy was made. Although MB is checked for its Rotor it clearly shows no blur

Funny enough, Motion Blur for the original object is getting errazed when I define new MB values for the copy only. Now only the copy shows Blur.

[JDHill]

Copies of objects with Motion Blur should inherit all properties. Therefor for these new objects also Motion Blur is checked on the Maxwell Properties page. In fact however, only the source objects will show Motion Blur.

I'm not sure if this is going to happen in the near future. It is only inheriting the mblur 'checkbox' status because Rhino is making a verbatim copy of the source object's attributes, where this is stored. I will try to find a way to un-check the box when objects are copied.

Now if I go ahead and uncheck MB for the copy and recheck it again, set a new MB start-position for the copy only, the original object loses its MB properties and only the copy shows up correcty.

How did you do this? I don't think there is any way to update the position for only one object in 1.6.1 (there will be).

Set up MB for my little Heli (Top and Rear rotors) create some copies and move these copies around in the scene and also tilt them in all axis.
The end result would be a nice array of helicopters in different orientations. Now say the MB inheritment would work flawlessly. Wouldn't additional movement and rotation for the rotors get tracked while I distribute the Helis inside the scene? Resulting in a very wild MB solution?

No, it wouldn't...in 1.6.1 the function is simply this:

frame 0 data: object ID, location/direction of the first mesh vertex
frame 1 data: object ID, new location/direction of the first mesh vertex

when you 'update' object positions, you set the data for frame 0 in an in-memory array. when you copy an object, this is done 'behind the plugin's back', and as I said above, the only reason the checkbox is still ticked is because of the direct copy of object attributes by Rhino.

I presently can not imagine solving this question without making this rotation a understandably "local" transformation around a fixed axis, which however may be moved around in space and rotated. This is where Bongo would have to come into play, no?

Sure, except that there is no such thing as a 'local' transformation for objects in Rhino - everything is always in wcs (besides for blocks). I did recently find a wonderful hack that would work for this while I was tuning up real scale, so the entire mblur situation may change in the future.

MB properties are not getting saved with the file. As a first workaround for quickly putting everything back into place I found the Rhino command NamedPositions helpful.

Yes they do not get saved, and they won't, in the current implementation. This is a runtime-only feature, the data is only stored in-memory, and it could be come quite huge (as full-range motion is now supported in the current build - this means a vertex/normal stored for each one in the mesh). NamedPositions is a much better solution, and I suspect it uses the hack I mentioned above to pretend that Rhino objects have a lcs.

A copy was made. Although MB is checked for its Rotor it clearly shows no blur

- addressed above - the checkbox status was copied by Rhino and the plugin doesn't know that

Funny enough, Motion Blur for the original object is getting errazed when I define new MB values for the copy only. Now only the copy shows Blur.

- addressed above - the copy shows blur because when you stored position for it, you also over-wrote the position of the original. That is, Maxwell_SetObjectsInitialPositionForMotionBlur updates position for all objects. This is not the case in the next version.


So in short, this is still a very young feature, and not one that Rhino lends itself to working with. I have an idea in my mind of doing this an entirely different way, so for the time being, it may not be exactly convenient in its implementation, but at least it gives access to the feature.

[kami]

Hi JD,

while we're at it with the plugin forgetting settings:
besides the city, which does hopefully work in the next release, i think my rhino doesn't remember the vignetting-settings either, when i reopen a file.
hope this'll be fixed too.
i'm so looking forward to the next release! great work!

greets,
kamii

[JDHill]

Thanks kamii,

The sun globe has been reworked alot (not visibly, but underneath), and it will now remember the city name. When you say 'vignetting-settings', you mean enable/disable, right? Because I looked and found it wasn't reading this back from the file - but it was reading the vignetting number. Is this consistent with what you're reporting?

Thanks,

JD

[kami]

Yes, it's only the enable/disable-switch which isn't working.
Thanks,
kami

[kami]

and there's another thing i noticed. not so much of a bug, but it seems to be a rhino-problem:
when i select an offset for the camera (y-offset or x-offset) then it doesn't show the offset in the rhino viewport. i suppose, there is no possibility to get this in rhino, is there?
and the second thing: when i want to render a region, and i have a camera with a heavy offset, the selected region in rhino isn't the region which it will render in maxwell. i always have to guess in which region the lamp will render in maxwell render to get a region render of an important object. this could be fixed i think ...
i hope you understand, what i mean. my english is a bit poor. =(

cheers,
kami

[JDHill]

Hi Kami,

Since Rhino was not primarily designed to be a rendering platform, it has a camera model which is very simplified when compared to the one provided by Maxwell. So as you guessed, it is just simply not possible to make the Rhino viewport show something like offset, or even a custom film size. However, for the next version I have built a system which will allow you to visualize all of the Maxwell parameters - it is a dynamic visual overlay which is drawn on the Rhino viewport, and it will show you exactly which portion of the viewport will be rendered, based on how all of the Maxwell-specific camera parameters are set.

Cheers,

JD

[Thomas An.]

HeadsUpDisplay turns the viewport blue and opaque:

[JDHill]

Sorry, all I can say is to play around with your video card and your Rhino video settings - a problem like this would be happening way below my code. I am going to add a less-fancy optional mode that will just use Rhino viewport methods and draw a yellow rectangle instead of the full heads-up-display.

[kami]

Hi JD
thank you so much for the new plugin. it's great so far!
i noticed one little bug on the scene manager shortcuts toolbar: the first button (camera) brings you to the "Date & Time Settings" instead of the "Camera Settings".
cheers, kami

[JDHill]

Thanks kami, you're right, and I have found the reason.

JD

[ricardo]

Hi JD, install for 1.6.8 failed for me, had to load it by hand. Let me know if there is something I can make to help you debug this.

That discounted, nice & easy. It's been a while I hadn't used Maxwell and the plugin is just amazing - I'll never look at studio agin

The other thing I'm happy with is rendering a full page add with complex IOR diamonds in my old Athlon 4200X2 over night.

[JDHill]

Hi Ricardo,

Thanks for reporting - do you happen to recall which version you were upgrading from? I wish I could take some credit for good rendering performance...but I can't.

Cheers!

JD