[numerobis]

yes, i always prefered to have the materials stored in the mxs - so that i have at least material state saved. The other dependencies (textures, mxs) are enough...

Why has this been changed? In max i can still save it in the mxs.

...The output macros work great!

[JDHill]

Well, it's not so much that it was changed, it just didn't used to be an option. The plugin allowed you to link to MXM files, but Maxwell didn't support that, so of course they had to be embedded; once Maxwell itself supported MXM references, it (seemingly) made sense that an MXM-linked material in the plugin would result in an MXM-linked material in the MXS. But I can see about adding an explicit option for embedding a linked MXM if you want that.

[numerobis]

But I can see about adding an explicit option for embedding a linked MXM if you want that.

Yes, please!!!

[numerobis]

There seems to be something wrong with the HDRI offset...
(rendered in Fire, but exported to Maxwell it looks the same)

[JDHill]

Definitely a bug -- it should help you to know that it's working in radians.

[fv]

JDHill,
to clearyfy 1. The word symbol is my fault, I use vectorworks components are called symbols there.
I think this is an old issue. We tested today with version 2 seeing the same problem.
Basicly, materials like glass (totally transparant) either ags or high grade are just invisible assigned to surfaces of a volume in a component.
Example, I make a component with a windowframe and a grouped glass volume in it like 1000x1000x20 mm assigned with a 100% transparent reflective material. The glass renders as an invisible object without any visable reflections. I noticed before that glass in my architectural renders did not really look good. Untill today I noticed a few glass objects as single objects outside the group or component did well. I thought it was a V3 issue. Maybe it still is. It seems a little inconsistent. I will send you a file.

I will update to 3.0.0.1 to see what happens with my other points and report back.


1. Sorry, but could you please clarify what you mean by saying "symbol"? It sounds like a case where I'll need to see a SKP model.
2. I'm not able to reproduce this, but wonder, have you checked it with the 3.0.0.1 version on the portal download page?
3. Yes, it seems so (on both Win & OSX), though not after clicking File > New. It appears to be due to opening MXS files that use the Direction method of sun location, as is always the case coming from SketchUp. I'll work up a report for the Studio developers.
4. Probably I would check 3.0.0.1 here, too.

[numerobis]

Definitely a bug -- it should help you to know that it's working in radians.

sorry, but for me it doesn't only look like radians instead of degrees...



And another problem with HDRI:
- using mxs-references with HDRI in Fire (no matter if using draft or production) i get a "The scene has errors" message:

Code: Select all

1. >> Error: Reading Bitmap "//SERVER/[folder]/[file].exr". Format not recognized. Render cannot continue.
2. Data preprocess failed. Render cannot continue.
3. startRender returned -1.

(file and folder names changed)

With phys sky it works fine. HDRI without referenced mxs too. And exporting to maxwell works

Btw. would it be possible to store the last file path for saving images in Fire? It always resets the path to "/Maxwell/output". Very annoying...

[numerobis]

Now, when i export a scene to studio the HDRI offset is changed to 360°/360° - the setting in sketchup is 240°/30°

Another "funny" problem. Last time i exported a scene to studio i got a missing texture warning for all referenced MXMs without textures:

Code: Select all

The following texture could not be found:
textures

Used in material: licht1 

Do you want to find a replacement?

i can hit ignore and it opens and renders normally.

I could export same scene before without any problems. I think the only difference was the "textures" folder the exporter had created at the previous export.


...but have to say again that i really love the macro naming feature!

[JDHill]

The value is definitely in radians -- to shift by one degree, you'd need to increase the precision of the sliders (using the little button at the right, in the UI), and set the value to 0.0174 (i.e. degrees * (pi / 180)).

Regarding the message from the engine about "format not recognized," where is this exr being specified -- actually as an IBL map in Scene Manager > Environment, or is it something inside the referenced MXS? In either case, if you trade it with one of the stock hdris in the Maxwell/hdri/dosch folder, does the error still occur? I'm not yet able, using a simple example, to reproduce this, and so will need more information.

On the FIRE image saving path, it is supposed to do that, but there is apparently some problem with it. I'll look into it. As for Studio asking about a missing "textures" texture, I have seen that too, but haven't yet figured out why it's looking for it.

[fv]

1. Does the exporter still adds the referenced mxs files placed in SU. When I export a pack & go I no longer see the referenced mxs files ? Or do I remember right that this is only possible exporting from Studio.

2. And the pack and go files no longer open properly since at opening the textures can not be found. The path does not seem to be corrected for the texture map included in the pack anf go. Exporting from SU. Exporting from Studio all is fine.

3. When I try to open a file on another system the floating license works fine with Maxwell but not for Studio. This is not really SU related I assume.

4. SU crashes rather easily with Fire. I would advise to save first before starting any Fire session from within SU. In Studio it does not seem to be a problem.


Anyhow, tx for all your work and the plugin. Hopefully the little bugs here and there are easy to fix.

Francois

[JDHill]

I don't believe referenced MXS (or MXM) files have ever been copied along with pack & go, since that would defeat much of the purpose of using referenced files. The MXS files may be large, so we lose the performance savings of using the reference, by copying the file. And it makes little sense to link to an MXM file, and then copy that file around to various places.

However, I can see arguments against this, since the way of using these things in SketchUp is probably a bit different than elsewhere; you're not using MXS references in order to share geometry among models, but rather to overcome memory & performance limitations in SketchUp. And you're not linking to an MXM in order to have a single material definition shared among models, but rather because that's the only way of using an MXM. So I am tending to think some changes should be made here; as numerobis was asking, regarding embedding of MXM files, there should be some options added, which allow you to decide whether an MXM is embedded or linked, and whether an MXS reference is copied with the model, or not. Does this also make sense to you?

Regarding textures being reported as not found, I think you are referring to the same thing also mentioned by numerobis above: when you open your MXS, Studio thinks there are missing textures. It is not looking for a file, though, but rather just "textures" (please confirm that's the same thing you're seeing), in every instance of the warning dialog.

[fv]

I have no problem exporting to Studio directly. Only when I do a pack & go to another system than I get into problems. Most likely because the mxm's are refenced instead of embedded. When I pack & go from Studio all works fine. The result can be rendered on another system without any errors. Since I have referenced mxs's exporting from studio is a must anyhow.

This problem comes up now because the network rendering no longer works here. It all starts up fine with the licenses found but the nodes never start rendering. What I do now is export P&G by Studio to a folder on the node system and render different images on that system. Normally I would render using the network rendermanager from my system by using a networkrendernode on another system. That way I can keep working on my system. That no longer works for some reason, I think unrelated to SU or the plugin.

The glass & reflection issue is still really weird. I can't use glass inside a component. I have to check if this is because of nested components or another modeling related issue.
Francois

[JDHill]

Pack & go should not make a difference, as long as your MXM files are on a network drive. The idea is that they are, so that no matter where you render the MXS that references them, you are rendering the same material. If the model is never rendered on another machine, then you shouldn't use pack & go at all, so it's not an issue there, either. However, I can't say much about any potential network rendering problems, since I don't have much experience with it. All I know is that I'd check the node/manager/monitor consoles to see if any errors are reported.

Regarding the glass/reflections issue, I guess I need to know what you mean by "inside a component." It could mean that you extruded a plane to give it volume, and then made it into a component, which should work fine, or it could mean that you have some glass objects inside of a room, which is a component. In the second case, I could see a potential problem, if you are viewing glass objects through other glass, and the scene is lit only by sunlight; that is a difficult case for the engine, which will take a long time (longer than you want to wait) to resolve, like sun-pool caustics. That'd be my guess, anyway, given that I don't yet understand the situation.

[numerobis]

The value is definitely in radians -- to shift by one degree, you'd need to increase the precision of the sliders (using the little button at the right, in the UI), and set the value to 0.0174 (i.e. degrees * (pi / 180)).

Interesting... i didn't know that i can change the precision there. I have to try it.
But i would prefer a fix to degrees if it is possible...

[fv]

to get back to get my glass issue.
I think I am having some trouble with double sided materials. It seems to me that inside a component or outside front and back materials are differently exported.

You are right to advise us to organize our material libraries on a server drive. But we are not as well organized and sometimes render at home, on an architects system that is in the same office building. Than it is ideal to do a pack & go that assembles all necessary files into one package.

Most likely our network problems now have to do with disorganized material libraries. But we had no trouble running network rendering with V2 at all. It was up and running in minutes without much hassle. I was expecting the same but as it is, it does not work. The console of the networkmanager does indeed show missing textures although I haven't had the time yet to fully see what the problem is. I would just like to know what the difference is with V2 and 3 for network rendering straight out of SU. I will test tomorrow if network rendering works from Studio. It just might. Just tried it but with no result. The nodes status is "rendering" but without any visable progress… Not working from SU or Studio.

Anyhow JD, tx for your fast response and willingness to get to problems that could just be caused by my rushed way of working. Our cliënts think we just press a button to get an image on the screen and pay us likewise….