[archigrafix]

How about some news on the progress of a version that completly works with those mxs?

[fv]

http://forums.sketchucation.com/viewtop ... 80&t=48050

I love this reference to mxs-instances from within Sketchup. Just incredible. This will also allow us to keep Sketchup files very clean. I only need to work on how to make the components in Sketchup scaled right and a little more revealing for what they represent.
Francois

[JDHill]

@archigrafix: the status is that it is not fixed yet.

@Francois: only the first component is exported as an mxs reference; further copies are exported as instances of that reference. The initial reference requires memory for loading whatever is contained in the mxs, but the instances are just instances, which is why it takes comparatively little memory. Regarding scaling, you should be able to move/scale/rotate the bounding-box representation of the mxs as you would any other component. Since it is just a component, you are free to edit and replace the bounding boxes with some other geometry; the size of the initial bounding boxes should accurately represent the geometry (meshes only, not instances) contained in the referenced mxs. If you edit the component and then want to go back, just right click the component and choose Maxwell > MXS Reference > Update Proxy; the plugin will re-read the MXS file and rebuild the bounding box representation.

[fv]

Tx, very clear.

I was just wondering as well why rendering 100 trees does not take much ram during rendering in Maxwell. 4Gb seemed to be more than enough.
This isn't related to the plugin. But when using the Grass menu I do run into problems with my limited 4 Gb of ram.
Francois

[JDHill]

Yes, since it can easily generate millions of blades, grass can take a lot of memory. To minimize usage, you might want to try the LOD feature, and of course, avoid using more density or points per blade than necessary. I am not sure I understand the comment about memory usage when rendering 100 trees; if you were referencing 100 different mxs files, that would use a lot of memory, but not if you are using 100 references to the same mxs.

[fv]

tx for pointing out the LOD feature.

On memory usage I tought that it makes a lot of difference to use instances or components for handling and exporting the file in SU.
But I did not know that to render a model it makes a difference to use instances. I thought that at the actual renderprocess wether the volume is an instance or not does not matter all that much in terms of system ram. The volumes, instances or not, are as much involved in reflecting light.

On the plugin,
I tested a bit more. When I start a new file, with a simple cube all renders fine. As soon as I insert an mxs-instance the filed of view, rendered without adding a scene, is off.
Something else I noticed that duplicating and moving an mxs-instance leads sometimes to misplacement in the rendered image. Maybe caused by errors related to the origin of the mxs-instance in SU.

Hope this helps a little in finetuning the plugin.
Francois

[JDHill]

It is to be expected that instances will take comparatively little memory, both in Fire in the plugin, and in Maxwell Render; reflecting/refracting/etc with an instance is only different in that it involves applying transformation from the original mesh to the instance location when doing calculations. So an instance is more or less a transformation that is named and associated with some physical mesh in the scene.

Regarding any glitches that seem related to enabling mxs references, it is very conceivable that you might run into such things; as far as I am aware, the plugin's code is fine, there are just some issues in the Fire engine, especially with instances of mxs references, and even more so where the mxs being referenced contains instances. Until the feature is official, you should expect to see such things; I revealed it here mostly to get feedback on how it has been implemented (the methods of creating, and working with mxs references) in the plugin.

[fv]

ok, tx. basicly what your saying is that 100 instances of the same reference renders faster and with less need of system ram than 100 groups of exactly the same geometry. Considering only the renderproces in Maxwell.

About the plugin,
I placed several mxs instances. Some with their origin central in the volume located and some with the origin at the centre bottem. If I align all mxs instances on the same plane, as you would with cars or trees some duplicated mxs instances show up at misplaced, lowered in my case. If I can reproduce this consistently I will send you the model.


I am aware that the plugin for mxs instances is not yet fool proof. It already works like a dream. Any inssues I might find I will let you know.
I would for trees, cars, people and so on replace the mxs-volume for a 2D image of the mxs model. That way there a little more to see when composing scenes and camera setup. Not sure yet how this can be done at import or if this is actually best to do manually.
Francois

[JDHill]

Instances take less memory, and they export faster, but they cannot render faster. This is the case both in Maxwell Fire in the plugin, and in Maxwell Render, and the cost, in render time, should generally be negligible. Regarding misplaced/misaligned mxs references, this is to be expected in this build, when rendering in Maxwell Fire -- that is precisely one of the bugs that needs to be fixed, so no need to send me any models demonstrating it. Regarding a 2D representation for the mxs reference component, I guess you mean that you want some sort of billboard showing a view of the MXS, but to do that, you'd need to render the billboard (in Maxwell Render, probably with alpha embedded) first. Then, you could modify your mxs reference component definition, inserting that image either as a face with a material, or as a SketchUp Image object.

[fv]

I just did a project with referenced trees, just worked great. It made a huge difference. I had no problems with misplacements or scale.

Just a few ideas;
it would be nice if at inserting an mxs reference apart from the bounding box also a origin guide was inserted. Just easier to see if a tree is on the road or beside it. Especially in perspective. I can do that myself after inserting but as things are hectic, a given origin would be helpful.

Another thing would be great if the plugin has a setting to insert an amount of mxs references on a selected group in SU. With settings for random placement, scale and so on. Even better would be if I could choose a group of mxs references to be randomly placed. Imagine 10 detailed people-mxs-models to be placed in SU a 100 times to model a busy square of people. A little forest, garden plants, etc.
It would also be nice if instead of a group you could choose lines to create a row of cars. Some of this can already be done in SU or by using oher plugins to place symbols.


One of the major qualities of mxs references is of course the option to have much more detailed models rendered straight from Sketchup. But another really important advantage is that the SU file will remain clean without all the extra materials from imported components. Especially since Sketchup can not organize materials in some kind of hiarchy. I hope Trimble will work on that as well.

[JDHill]

If you look at the proxy geometry, you should find a datum indicating the world x/y/z origin of the referenced mxs -- it is a circle with cross-hairs. On randomly scattering mxs references around, this is more on the content-creation side of things, and since the mxs reference is just a plain component definition, I will probably not do that and let people use other plugins to scatter them around. With the new Maxwell Extensions, I might speculate that we could see a render-time tool like this show up in the future; it wouldn't be too difficult, for example, to use the random scattering logic of the grass extension for distributing instances of objects across a plane.

[fv]

Hi,
yes I saw that crosshair in SU in one of the mxs-references and thought it was because of the mxs model itself. I did not see it in SU in any of my other mxs references. If its there it might be located away of the mxs geometry. I am sure there is a tool in Studio to centre the origin so the crosshair will be visible in SU.