Maxwell Render | Official public forum

i've got an issue here, which i was not able to figure out.
it's about hdri lightstudio 4 in conjunction with the plug-in (tried 2.7.20 and 2.7.23) on both r13 and r14.

it's not directly about maxwell i guess, but i'm not sure, since the presence/absence of a maxwell-plug makes the difference (in r14).

but first things first:
this is the console message i receive, when i use the hdri lightstudio plug-in in both releases r13 and r14:

in both releases, i tried deleting all directories within the plug-in directory, except for the hdri lightstudio plug-in, but still i get this message. so no matter what, i permanantly get this message. so much for that background.

this is what i get in livelight, when i export a simple cylinder-on-plane scene with r14:


this is the same scene with r13:


so in every case (verions 2.7.20 & 2.7.2.3), the export with r13 works just fine.
in r14, the export only works fine, if the maxwell-plug (no matter, if it's 2.7.20 or 2.7.23) is NOT installed.
as soon as i get a maxwell plug-in back into the plug-in directory of r14, the export looks messed up like above.

so, not sure... what to think of that?

Regarding the first issue, that would seem to point to some problem with the hdrls plugin. All plugins (and commands, tags, etc) in Cinema are required to have a unique ID number, which you must obtain from Maxon. The message being printed there indicates that two items with the same ID are present. The ID mentioned is not one used by the Maxwell plugin, and indeed, as you write, that error is occurring whether Maxwell is present or not. So that's about all I can tell you about that.

As for the second, I am not clear on what you mean by "export". I assume the hdrls plugin has some command for writing the hdri to disk, and that this is what you mean. I'm not sure how our plugin could affect that, but I'm downloading hdrls demo now, and will take a look.

Regarding the first issue, that would seem to point to some problem with the hdrls plugin. All plugins (and commands, tags, etc) in Cinema are required to have a unique ID number, which you must obtain from Maxon. The message being printed there indicates that two items with the same ID are present. The ID mentioned is not one used by the Maxwell plugin, and indeed, as you write, that error is occurring whether Maxwell is present or not. So that's about all I can tell you about that.

wouldn't that mean, that this could not happen, if the hdri plug-in would be the only plug-in installed? as written, it still showed that message though everything else had been removed.

As for the second, I am not clear on what you mean by "export". I assume the hdrls plugin has some command for writing the hdri to disk, and that this is what you mean. I'm not sure how our plugin could affect that, but I'm downloading hdrls demo now, and will take a look.

sorry for being unclear.
i meant "export" in a way similar to the maxwell plug-in: one can press the export button within in the hdri-plug for c4d and it's being exported a scene that is automatically opened in the hdri lightstudio standalone application (which has to be opened, waiting in the background) and directly shown in the live light preview of that app (somewhat similar to fire within mr-studio).
it says in the .pyp-file, that two file format are being used to export a scene from c4d to the host app: .dae and .obj. while .dae would be preferred:

the .pyp-file of the plug wrote: # Export format to use
# 0 for C4D [ Debug mode. Can't be read by LS, but allows exported file to be loaded back to C4D for comparison with original ]
# 1 for DAE ( Collada 1.5 ) [ Preferred format for LS ]
# 2 for OBJ [ Works with LS, but camera and e.g. Phong tag data not exported ]
gExportFormat = 1 # Recommended: 1

when the scene is being exported into a temp-file, the process is somewhat automatic: the scene is being shown and rendered within the host app's livelight.
but, one can also export to a file instead. then a path and filename has to be chosen. it exports out a .dae file when nothing but the filename is given. after that one can manually open that file within in hdri-lightstudio but, no difference. still the same messed up geometry.
once again: this only happens, if the maxwell plug-in also is installed.
and it also only happens on r14. on r13 everything works just fine. wether the maxwell plug-in is installed or not.

thank you for looking into it.

mashium123 wrote:

Regarding the first issue, that would seem to point to some problem with the hdrls plugin. All plugins (and commands, tags, etc) in Cinema are required to have a unique ID number, which you must obtain from Maxon. The message being printed there indicates that two items with the same ID are present. The ID mentioned is not one used by the Maxwell plugin, and indeed, as you write, that error is occurring whether Maxwell is present or not. So that's about all I can tell you about that.

wouldn't that mean, that this could not happen, if the hdri plug-in would be the only plug-in installed? as written, it still showed that message though everything else had been removed.

No, for instance, if I added the new Maxwell Hair tag, but accidentally re-used the ID for the Maxwell Particles tag, I would run into this problem. It would also happen if I attempted to register the same tag (or command/object/material) twice.

On the rest, thanks for the additional detail, I'll see what I can find.

Well, it appears the first issue is due to two copies of the plugin being included in the plugin folder. It is a python plugin, and you will find that there are both HDRLightStudio.pyp and HDRLightStudio.pype files in the plugin folder. To my understanding, a .pype file is a .pyp (python) file that's been encrypted by Cinema using the "Source Protector" function. So ostensibly, both of these files contain the same code, in which case the error message would be due to attempted double-loading of the same plugin. I'm not well-versed in python for Cinema, though, and this is something for the hdrls people to deal with.

JDHill wrote:Well, it appears the first issue is due to two copies of the plugin being included in the plugin folder. It is a python plugin, and you will find that there are both HDRLightStudio.pyp and HDRLightStudio.pype files in the plugin folder. To my understanding, a .pype file is a .pyp (python) file that's been encrypted by Cinema using the "Source Protector" function. So ostensibly, both of these files contain the same code, in which case the error message would be due to attempted double-loading of the same plugin. I'm not well-versed in python for Cinema, though, and this is something for the hdrls people to deal with.

moving one of them out of the directory dealt with the first issue. one down, one to go

Yes, but you should ask the hdrls people if it matters which one you remove.

yes, those are the ones that i would have turned to but in the first place. but since the r14-issue with the messed up geometry (or phong or such...) only appears in conjunction with our maxwell-plug, i thought, i'd give it a shot and let you know first.

Turns out it will take awhile for me to check the second thing, I am developing the R12/13/14 plugins using the Cinema demo, which can't save files, and the hdrls plugin needs to save files. I tried activating the "42 days" demo license, but it failed...same thing happened when I tried to do that with R13.

Here, anyway, is the first thing I would check: set gExportFormat = 0 in the .pyp file to export using .c4d, and then check to see what is actually being written. Write one file that way with the Maxwell plugin installed, and one without...compare them and see what is different. Next, I looked at the python, and it works very differently if you are using the export "all" or "selection" options. In the first case, they ask Cinema to clone the document, while in the second, they do a bunch of manual cloning of the selected object hierarchy. So I'd see if/how those behave differently, depending on whether the Maxwell plugin is installed. Lastly, I'd try using the OBJ export option, just to see if the issue is localized to the DAE export. Since they end up asking Cinema to save the document, and since you say that you are seeing a difference between R13 and R14, it could be that something is working differently in DAE export between the two Cinema versions. You probably want to check and make sure your DAE export settings are not different between R13 and R14 too -- it occurs to me that it could conceivably come down to how the materials are written.

ok, i'll try not to screw up and report back.

here's the source scene for the following tests:
http://www.mesutcapkin.com/temp/r14_source_scene.c4d

...
set gExportFormat = 0 in the .pyp file to export using .c4d, and then check to see what is actually being written. Write one file that way with the Maxwell plugin installed, and one without...compare them and see what is different.

done. exported to c4d-file with and without maxwellplug and opened those in c4d again. i see no difference.
here's the files:
http://www.mesutcapkin.com/temp/r14_c4d_w_mr.c4d
http://www.mesutcapkin.com/temp/r14_c4d_wo_mr.c4d

Next, I looked at the python, and it works very differently if you are using the export "all" or "selection" options. In the first case, they ask Cinema to clone the document, while in the second, they do a bunch of manual cloning of the selected object hierarchy. So I'd see if/how those behave differently, depending on whether the Maxwell plugin is installed.

done. again: no difference - with the export set to 0 (c4d-file). except for: the object line-up in the object manager is reversed in the files, that are generated via selection-export and the default color for objects in the editor is being set to the darker grey-blue default setting (attributes-managaer->mode->project):
http://www.mesutcapkin.com/temp/r14_c4d ... ection.c4d
http://www.mesutcapkin.com/temp/r14_c4d ... ection.c4d

now, with the export set to 1 again (dae), here comes the differences. with the maxwell-plug installed, you get your screwed up geometry:
http://www.mesutcapkin.com/temp/r14_dae_w_mr.dae
http://www.mesutcapkin.com/temp/r14_dae_wo_mr.dae
the same goes for the selection-exports:
http://www.mesutcapkin.com/temp/r14_dae ... ection.dae
http://www.mesutcapkin.com/temp/r14_dae ... ection.dae

Lastly, I'd try using the OBJ export option, just to see if the issue is localized to the DAE export.

done. no problems whatsoever:
http://www.mesutcapkin.com/temp/r14_obj_w_mr.obj
http://www.mesutcapkin.com/temp/r14_obj_wo_mr.obj
http://www.mesutcapkin.com/temp/r14_obj ... ection.obj
http://www.mesutcapkin.com/temp/r14_obj ... ection.obj

Since they end up asking Cinema to save the document, and since you say that you are seeing a difference between R13 and R14, it could be that something is working differently in DAE export between the two Cinema versions.

and here's the r13 files - nothing wrong with those exports:
http://www.mesutcapkin.com/temp/r13_dae_w_mr.dae
http://www.mesutcapkin.com/temp/r13_dae_wo_mr.dae

You probably want to check and make sure your DAE export settings are not different between R13 and R14 too

had done that yesterday. export settings for all dae-versions are set to same value in both r13 and r14.

-- it occurs to me that it could conceivably come down to how the materials are written.

now i opened both the r13-dae and the r14-dae with a text editor and try to read what's in there. since i'm a non-coder, it's more like a game:"what's different in the right picture, compared to the left one?"

Wow, nice...let me take a look at all this.

ok, i found a difference while comparing r13-dae and r14-dae, both with installed maxwell plug-in.

r13 dae wrote: <node id="ID8" name="Zylinder">
<translate sid="translate">0 100 0</translate>
<rotate sid="rotateY">0 1 0 0</rotate>
<rotate sid="rotateX">1 0 0 0</rotate>
<rotate sid="rotateZ">0 0 1 0</rotate>
<scale sid="scale">1 1 1</scale>
<instance_geometry url="#ID9">
<bind_material>
<technique_common>
<instance_material symbol="Material1" target="#ID1">
<bind_vertex_input semantic="UVSET0" input_semantic="TEXCOORD" input_set="0"/>
</instance_material>
</technique_common>
</bind_material>
</instance_geometry>
</node>
<node id="ID17" name="Ebene">
<translate sid="translate">0 0 0</translate>
<rotate sid="rotateY">0 1 0 0</rotate>
<rotate sid="rotateX">1 0 0 90</rotate>
<rotate sid="rotateZ">0 0 1 0</rotate>
<scale sid="scale">1 1 1</scale>
<instance_geometry url="#ID18">
<bind_material>
<technique_common>
<instance_material symbol="Material1" target="#ID1">
<bind_vertex_input semantic="UVSET0" input_semantic="TEXCOORD" input_set="0"/>
</instance_material>
</technique_common>
</bind_material>
</instance_geometry>
</node>

while

r14 dae file wrote: <node id="ID8" name="Zylinder">
<translate sid="translate">0 100 -0</translate>
<rotate sid="rotateY">0 1 0 -0</rotate>
<rotate sid="rotateX">1 0 0 0</rotate>
<rotate sid="rotateZ">0 0 1 -0</rotate>
<scale sid="scale">1 1 1</scale>
<instance_geometry url="#ID9">
<bind_material>
<technique_common>
<instance_material symbol="Material1" target="#ID1">
<bind_vertex_input semantic="UVSET0" input_semantic="TEXCOORD" input_set="0"/>
</instance_material>
</technique_common>
</bind_material>
</instance_geometry>
</node>
<node id="ID17" name="Ebene">
<translate sid="translate">0 0 -0</translate>
<rotate sid="rotateY">0 1 0 0</rotate>
<rotate sid="rotateX">1 0 0 90</rotate>
<rotate sid="rotateZ">0 0 1 -0</rotate>
<scale sid="scale">1 1 1</scale>
<instance_geometry url="#ID18">
<bind_material>
<technique_common>
<instance_material symbol="Material1" target="#ID1">
<bind_vertex_input semantic="UVSET0" input_semantic="TEXCOORD" input_set="0"/>
</instance_material>
</technique_common>
</bind_material>
</instance_geometry>
</node>

in the r14 dae "translate sid" and "rotateZ" are both valued "-0" in their last column while r13 dae has "0".
is that it? if so, what do i do about it?

ok, that does not seem to be it.
next step: compare r14 dae with maxwell and without maxwell.
it seems, that with the maxwell plugin installed non-integer values are being written with a comma e.g. "852,6" and without maxwell plug-in installed they are written with a dot e.g. "852.6"

is it that? me, guessing around