[JDHill]

Well, I suppose I can post some links here, buried in this thread, so you can try out the build. It is very pre-release (i.e. it has only been tested here by myself), so use at your own risk and all the other disclaimers apply -- maybe it's perfect, and maybe not.

There are not many visible changes, as most of the work has been in getting cross-version compatibility restored.

Code: Select all

Maxwell for Cinema 4D 2.1.1 

changes

- Added support for Cinema 4D R12.
- Improved Cinema material translation with respect to Reflection channel.

fixes

- Objects which inherited materials from another tag could have incorrect UVs exported.
- UVs were fit to object size when Texture Tag Tiling was disabled.
- Maxwell Instances of object hierarchies could have incorrect relative transformations.
- Maxwell Instances of object hierarchies under Mograph Cloners could have incorrect transformations.

And here are the download links:

• Maxwell_for_Cinema_4D-2.1.1-R9.6-R11.zip
• Maxwell_for_Cinema_4D-2.1.1-R11.5.zip
• Maxwell_for_Cinema_4D-2.1.1-R12.zip

Of course, please do not share these links or release info outside of this forum. If you find any issues, please just report them here in this thread.

[Aniki]

Very appreciated, will check it asap;)

Thanks for the work!

Aniki

[jc4d]

Hi JD,
Thanks for this pre-pre release

The problem with the autoinstances is still here.

Here is the file reduced to it´s minimun where the problem is visible, maybe is easier to track down the bug now.
http://www.4shared.com/file/Qcp2ANXW/Autoinstance2.html
C4D R10.1 win XP 32bits

Cheers
JC

[macray]

works fine here atm. thanks for the pre-release!

[JDHill]

The problem with the autoinstances is still here.

Hi JC, I will respond in that thread.

[macray]

the new version seems to have a problem with the render region.

it works fine, but applied to an object other than the top one in the hierarchy it screws up the current display window.
if necessary i'll show some screens...

maybe this has something to do with the display driver issues R12 seems to have on different cards. Could someone try it on their hardware? (I got a nvidia Quadro FX 1600m here.)



edit: otherwise I haven't found a problem till now.

[JDHill]

No, I see that here too, but I don't yet know if it's an R12 problem, or a problem with my code needing special changes for R12. It only seems to happen when I try to draw 2D lines from code in a tag object like the render region.

[Aniki]

also I cannot combine realflow plugin loaded particles to render as rfrk via maxwell..

please add that feature in future releases

cheers

Aniki

[jwiede]

JDHill, don't suppose you can give us a hint whether C4D will be one of the platforms supporting plugin realtime previewing?

While working with the R12 beta this week, I noticed that Cineview seems to do a better job now with Maxwell materials. OTOH, I ran across some odd behaviors in how Maxwell materials show up in OpenGL / Enhanced OpenGL viewports: I had a black leather surface showing up as light purple under either OpenGL, for example.

How much of Maxwell material properties can we reasonably expect to "survive" and show in the OpenGL viewports? Are proxy C4D materials still the recommended approach for OpenGL viewing?

Finally, is 2.1.1 still the latest version available for the R12-compatible plugin?

Thanks!

[JDHill]

The 2.1.1 build linked above is currently the only build available for R12.

Regarding Maxwell materials in the Cinema viewport, they are designed much more for function than for beauty; in the case you mention, it is fairly certain that your leather material had a normal map selected for viewing in the viewport. This is controlled (similar to MXED) in the plugin's material editor -- see the 'Active Texture' dropdown, which is right next to the 'Refresh Preview' button. When no texture is selected, the basic color of the material will be shown in Cinema's viewport.

For any serious Cinema rendering, you will want to use Cinema materials.

Regarding interactive preview, I do not think I've said anything previously, but the short answer is yes, it will be implemented here. However, it will take longer to than with some other plugins. Some substantial redesigning of the plugin will likely be necessary.

[jespi]

Hello JD,

What about the new Render Queue feature in R12? Do you think is possible to integrate this with maxwell's plugin?. Would be very handy.

Thanks,

José

[JDHill]

Well, seeing that the plugin is less a rendering plugin and more a file exporter with a very extensive UI, I would say no. However, it really depends on this:

Regarding interactive preview...some substantial redesigning of the plugin will likely be necessary.

[jwiede]

Regarding Maxwell materials in the Cinema viewport, they are designed much more for function than for beauty; in the case you mention, it is fairly certain that your leather material had a normal map selected for viewing in the viewport. This is controlled (similar to MXED) in the plugin's material editor -- see the 'Active Texture' dropdown, which is right next to the 'Refresh Preview' button. When no texture is selected, the basic color of the material will be shown in Cinema's viewport.

Yeah, that's precisely what was occurring. However, did you realize that when MXM linking is enabled, it's automatically choosing the normal map for viewing (instead of the color, which is what I'd expect)? Also, I'm a little confused as to why I have to disable MXM linking to make changes to the "C4D-side" attributes of the material (such as the bitmap used for OGL preview)? If I wish to use MXM linking, how do I adjust the C4D-side attributes of the MXM file itself?

To me, it feels like the control for which "map" is presented by C4D as the material's "preview surface" should live within the "C4D Maxwell Material" representation (and be saved in the scene), instead of being tied to the MXM. That way it can be adjusted, even when the user pulls all MXMs from a common (and write-protected) material library. Right now it seems like users of material libraries are kind of stuck with whatever is automatically selected.

(edit) Ideally, it'd let me choose which of Maxwell material preview bitmaps gets used for each channel, and store that in the scene. Of course once realtime preview is working, I guess it can automatically sample the preview image instead of having to guess w.r.t. view angles, anisotropy, etc. which turns out to be the dominant surface color/texture, etc. Until then, though, seems like I can probably choose better than it can guess using just material info.

Regarding interactive preview, I do not think I've said anything previously, but the short answer is yes, it will be implemented here. However, it will take longer to than with some other plugins. Some substantial redesigning of the plugin will likely be necessary.

I'd imagine the sheer existence of the "Cineview" plugin for C4D demonstrates that all APIs needed for preview rendering in a C4D view are available, since that's precisely what Cineview does (using the C4D AR engine). I can understand how you might not have structured the plugin to pick up all the necessary update messages, etc. and will have to restructure for those, though. I'm just glad to hear we'll be getting it.

[JDHill]

Yeah, that was precisely what was occurring. However, did you realize that when MXM linking is enabled, it's automatically choosing the normal map for viewing (instead of the color, which is what I'd expect)?

What you may not be aware of is that this is not being randomly selected: the MXM also contains the name of which texture should be considered as 'current'. So when you link to the MXM, the plugin uses the current texture it finds there.

Also, I'm a little confused as to why I have to disable MXM linking to make changes to the "C4D-side" attributes of the material (such as the bitmap used for OGL preview)? If I wish to use MXM linking, how do I adjust the C4D-side attributes of the MXM file itself?

To me, it feels like the control for which "map" is presented by C4D as the material's "preview surface" should live within the "C4D Maxwell Material" representation (and be saved in the scene), instead of being tied to the MXM. That way it can be adjusted, even when the user pulls all MXMs from a common (and write-protected) material library. Right now it seems like users of material libraries are kind of stuck with whatever is automatically selected.

Well really, it is just because when you say you want to link to an MXM, the plugin assumes that is what you mean to do. There would be arguments on both sides for breaking the linking paradigm for something transitory like the 'current' texture, of course, but it is such a corner case; if you just specify the desired map in the MXM, then there should be no issue at all.

(edit) Ideally, it'd let me choose which of Maxwell material preview bitmaps gets used for each channel, and store that in the scene. Of course once realtime preview is working, I guess it can automatically sample the preview image instead of having to guess w.r.t. view angles, anisotropy, etc. which turns out to be the dominant surface color/texture, etc. Until then, though, seems like I can probably choose better than it can guess using just material info.

Yes, it is my opinion that interactive preview potentially changes nearly everything about writing a Maxwell plugin. As you correctly guess, there is currently a whole bunch of code in the plugin which attempts to guess at what a material will look like when rendered; that code basically becomes obsolete once it is cheap to simply render it. Even more, how it works is that Cinema asks me for a bitmap to use for the viewport representation of a material; with the engine in the plugin, I'll probably just render that, instead of manually writing it in RGB.

[3DFX]

Can you give a approximate estimate on when the Cinema 4D Plugin for 2.5 with FIRE might take to complete? January, February, March?

Thanks!