[JDHill]

I'm unclear on what you meant by 'plugin does not recognize my .hdr file and greys it out' -- do you mean OSX does not allow you to select this file in the file chooser dialog? If so, try setting Scene Manager > Options > User Interface > File Browsers to Default and see if that helps.

[fv]

Yes, that helped. Why did this happen. Is there something with the hdr after I changed its saturation in PS.
TX anyhow, this made me go back into Studio.

Ps
just made this table straight out of SU with your new plugin.
http://web.me.com/fillieverhoeven/archi ... table.html

The glass with 1mm beveled edges gave lots of problems. I noticed that I often need to upscale my model a 100 times to properly work on details that are modeled below 1 mm. Then scale back. Otherwise SU is not accurate. Maybe on export to Maxwell sometimes accury problems with the geometry occur. I know this is not really what SU is meant for.

[fv]

I sometimes see misplaced mappings. For instance I mapped a wood texture on a beam and although it looked good in SU no matter what I do the texture is rotated 90 degrees fo the rendered results were I had rotated it in the right direction.
I looked if an override was set but it was just set as default.

Francois

[JDHill]

Yes, that helped. Why did this happen. Is there something with the hdr after I changed its saturation in PS.

I am not sure yet, it seems due to some permissions issue in OSX, where ownership is different for the modified file, which is then not being made available in Finder when viewed from the file chooser. I consider it a low priority, since the custom file browsers are only being provided to improve on SketchUp's poor standard Ruby choosers.

The glass with 1mm beveled edges gave lots of problems. I noticed that I often need to upscale my model a 100 times to properly work on details that are modeled below 1 mm. Then scale back. Otherwise SU is not accurate. Maybe on export to Maxwell sometimes accury problems with the geometry occur. I know this is not really what SU is meant for.

Yes, apparently SketchUp's precision is quite limited. In this thread, John Backus implies that it may actually only be 0.01 inches.

I sometimes see misplaced mappings. For instance I mapped a wood texture on a beam and although it looked good in SU no matter what I do the texture is rotated 90 degrees fo the rendered results were I had rotated it in the right direction. I looked if an override was set but it was just set as default.

If you can send me a model where this is the case, that would be good. I am aware of one scenario already where SketchUp is not giving correct UVs, i.e. the ones given are different than shown in the SketchUp viewport. Your issue could be related to that, or it could be due to some plugin issue.

[fv]

Tx for the quick answers again.

I wanted to sent you the file but could not simply reproduce the problem. I ungrouped the geometry and the problem was gone. grouping again the same geometry the problem came back. Nothing complicated though although the texture is high res (65Mb) in mxed but low res 256 Kb in SU. As soon as I have the time I will try to seperate the "problem geomtry" from the rest and send it.
Francois

[messire]

Small basic question ( unrelated to francois's)
When in SU i'm trying to use the mxm's, some appear greyed, and cannot be selected, and some are normal and can be selected.
Could it come from the fact that i still have a Maxwell 1,7 folder along the MR 2 folder. I have noticed that mxed uses the mxm from the 2 folder BUT the jpegs from the MR 1,7 folder for a given mxm file....this is weird...
THere could be another reason why i cannot choose all the mxm's i want!
Can i get rid of the 1,7 folder and relink automatically the mxm's to the mR2 textures? will it happen on its own?

THnx
Nils

[JDHill]

As I wrote above, the current workaround for greyed-out MXM files is simply not to use the custom file browsers. Probably I am asking OSX to create them in an incorrect way; I don't know at this point, as I have not looked into it much yet.

As to the wrong textures being used, I could not really say. When you render from SketchUp, does the correct (i.e. V2) version of Maxwell start? If so, then that is the only version of Maxwell on your system of which the plugin will be aware. And vice versa, if it starts V1.

You can always try renaming the V1 folder and see if the textures are then found in the V2 folder; it is difficult to predict, because both the plugin and Maxwell attempt to fix up paths. As I say above, for the plugin, it should only be aware of the directory of the Maxwell which is started when you render from the plugin; that will be the directory that OSX considers to be the 'real' Maxwell folder on your machine.

[fv]

About the mapping doing strange things,
in my case, my faulty textures were applied to the backside of the face. For some reason, even if you turn on "use front or back" the mappings on the backface are rendered differently than the frontfaces that render correct. My backfaces when he frontface has a defaulttexture (don't know if that matters) have rotated mappings, looking like normalized mappings, in my case often rotated 90 degrees from what I see in SU. Sometimes this is difficult since SU easily swaps textures to the backside without any visable clue other than the entity setting.

Hope this helps.
We do see more mapping problems, not just with SU but also with models made in Modo. Sometimes in Studio mappings are wrong and difficult to adjust in Studio. It could have to do with faulty object parameters needing to be reset which worked for us sometimes.

I am in a big project right now and still doing very little in Studio. Had not expected this. The plugin is an enormous timesafer compared to how I worked before. its a good thing I am accustomed to Studio as well but the need for it is 90% less than before making geonetry editing while doing test renders much and much easier. That also has its possitive effects on the design itself which evolves quicker and with much less frustrations.
Especially the camera settings in SU, the environment settings and the ease of exporting to Studio even just selected geometry is great. The whole process is now much more transparant and the horrible automxm is no longer an issue. I haven't had any textures yet that were not set correctly. I use the edit mxm a lot in SU.
What I need most know is a good counter for each render. Its beginning to be a hassle for each render, sometimes every few minutes or so (my manual live preview), to click on the output settings and set a new name and go back to the others settings again. Actually rendering over a previous rendering is the most common mistake we make here. Just before a deadline sometimes a costly mistake as well.



Francois

[JDHill]

I suppose there could be an issue with UVs vs. back face textures, but testing the theory, I am not seeing one here yet, so if you have a sequence of steps that will reliably reproduce an error, that would be best.

And yes, auto-naming for output files is on my list.

[messire]

"the current workaround for greyed-out MXM files is simply not to use the custom file browsers"
I'm not sure what u mean by custom file browser...


is it using this panel? how am i supposed to use mxm's without using this panel? ( i have to say am not yet used to the material workflow in the new plugin, the rest is almost perfect thu)

What i'm not sure is why some are greyed out and some are not? it seems random really within the folders

As for folders prb: I got rid of all V1 folders so now it only uses the V2 mxm's and textures

Nils

[JDHill]

The Custom File Browsers option is global, found here: Scene Manager > Options > User Interface > File Browsers. If you set that to default, then the plugin will just use the standard browser supplied by SketchUp's Ruby interpreter, rather than asking OSX for customized File and Folder browsers.

[fv]

I had a strange problem yesterday. I am in a competition presentation and tried to hide my emitters from camera, reflection and set the emitter material 100% white and with an Nd=1

I exported to Maxwell but the emitters themselves still showed up as white spots.
I opened the file in Studio and saw there that the emitters are hidden from GI instead of the camera. No matter what I tried, the "hide from camera" was exported as "hide from GI".

I will send the file later after I finish this work next week.
I also exploded the emitters to just a single group and the problem still persisted. In a new file the emitters pasted in a simple room worked fine hidden from the camera only giving light but invisable themselves.
Francois

[JDHill]

A file would be good, because I am not able so far to make a 'hidden from camera' group export to Studio as 'hidden from GI'. I don't really see any code path which could allow that to happen.

[fv]

TX, for your quick reply.
Actually, the emitters were reflecting in a glass surface, but all hiden for the rest. I switched of reflections as well and all was good. When I opened the file before in Studio I thought I saw the emitters hidden from GI. I must have been mistaken, incredible stress at the moment, deadlines almost impossible to meet. But your plugin does well and I see very few problems others than those mentioned here and I avoid negative scaling and so on as much as possible.

I just switched on instances again and I see a big difference in startup times for a preview in Maxwell compared to instances switched off. The difference is a 50 Mb mxs or a 6 Mb. The difference in startup times is more than I expected.
I switched it off to avoid problems with components/instances, although I don't experience any at this moment.
Francois

[JDHill]

Yes, it should take more time to voxelize a scene with instances enabled. But it will also take less (potentially much less, depending on the scene) time for the plugin to export the MXS.