[fv]

JD,
I hope you have not skipped the proxy option for components. We use it all the time for trees, people and furntiture for interior renderings. How would we otherwise have those dozens of high polygon Eames chairs in our office interiors, I don't think your speed optimalisation efforts will make up for the loss of the proxies. Anyhow, Sketchup would not be able to handle even a moderate number of component copies. The proxies make it possible to generate geometry that is otherwise impossible to generate with Sketchup.
Usually we do proxy work in seperate files in seperate exports to mxs. Then when the proxied geometry looks good we import it to be rendered in the rest of the model.

Richard, tx for your copy/paste suggestion, I understood what you meant by it. Its actually handy to keep an empty copy of the active file around for export. Better than opening a new file that would not export properly.

Francois

[JDHill]

I'll look into it Francois. It's interesting to me though: the essence of what you wrote above is that SketchUp would not be a viable modeler for you, at all, without this specific feature of the current Maxwell plugin. If it's that important to you, you really do need to make sure you're also requesting that Google fix the problem where it truly exists, as I wrote about Maxon doing for Cinema, in my previous post.

[Half Life]

Well, the real problem with Sketchup isn't poly's IMO you can work with a million poly's without too much of a problem -- but you have to be careful with the internal render engine of Sketchup as a few seemingly harmless settings can make the program slow to a crawl... and of course any materials that are not simple solid colors will make that problem many times worse. Which is not too big of a problem for me as the UV layout options native in Sketchup are so pathetic as to be basically useless for working with any non-flat surface. So I basically never use "textures" in Sketchup and instead take care of all that in studio.

Actually as a basic poly modeler I find Sketchup (with a few choice plugins) to be everything I need for most man-made objects and of course the native render engine is fantastic if you're intending to recreate the look of a drawing (which is an important feature in my field).

But my goals, being a Fantasy/Sci-Fi artist are very different in both Sketchup and Maxwell than the goals of say an Arch-Viz guy.

So from my POV the most important element of the Sketchup to Maxwell link is maximum power and flexibility with regards to Sketchup exporting geometry to Maxwell Studio (which is where I composite geometry, assign complex materials, manipulate UV's, work with HDRI's, etc.) and to me Proxies and Instances are a big part of that because it allows me to be able to sidestep many of the limitations of Sketchup for large scene layout -- which I do tend to prefer to do in Sketchup as without support for the 3D connexion tools navigating in Studio can be much more cumbersome than in Sketchup (which supports 3D connexion tools).

Thanks for all your hard work JD!

Best,
Jason.

[brodie_geers]

I'll look into it Francois. It's interesting to me though: the essence of what you wrote above is that SketchUp would not be a viable modeler for you, at all, without this specific feature of the current Maxwell plugin. If it's that important to you, you really do need to make sure you're also requesting that Google fix the problem where it truly exists, as I wrote about Maxon doing for Cinema, in my previous post.

I think there's a lot of truth there, in that Google really needs to work on the poly issue. However, to stick up for Francois a bit, I think what he's describing is sort of an issue in between modeling and rendering. SU can model an eames chair and Maxwell can render 100 eames chairs. And the problem isn't really even that SU can't contain 100 eames chairs, it's that w/o proxies, you have to display all 100 eames chairs in order to get them to export.

Now that I say that though, wasn't there a discussion about being able to export objects from hidden layers? It seems like that alone would replace the proxy feature, would it not?

Personally, we're lucky enough to have 3ds Max here as well which I use to supplement when it comes to high poly objects. It's not an ideal workflow but I've found it more manageable than proxies.

-Brodie

[JDHill]

Well, the silly part is that the capability is already 100% there in SU -- rotate a huge model and see how the display is optimized to bounding boxes during the rotate. All that is needed is for Google to expose that behavior as a standard display option for layers, or even for individual components/groups. The alternative is having every plugin on the face of the earth implementing clumsy, undiscoverable hack workarounds -- and since you can't draw in the viewport (except when executing a tool), these are all limited to being based on hard-to-manage and error-prone methods like string-match substitution, etc.

[Richard]

Mate Google get absolutely get hammered about the poly issue by users and even in every test I've done they cop it there from day one also!

[fv]

JD, the proxy thing is not all that difficult for the user. Most just use it for 1 or 2 components in a model in specific cases. Like with the new fur maker plugin, there it is really handy scattering around proxy-people and trees.

Actually exchanging SU materials for MXM's is done in more or less the same frame of mind. Maxwellrender does photorealism and for that to work out well you need photorealistic geometry almost as much as you need photorealistic materials.
Its true that SU is not the best tool for modelling photorealism. But since most architects use SU and since there is a huge library of components it still makes sense to use Maxwell in combination with SU. Any help from the plugin to keep adding geometry into Studio makes Maxwellrender stand out above the crowd.

I would agree though that proxy components as they are, are not a major issue, unless of course you can exchange them for .mxs "components".

I hope these discussions here on the forum do not distract you from finishing the plugin since I can't wait to use it after you let us in on what you have been doing.
Tx, Francois

[fv]

I saw a solution for proxy's.
http://forums.sketchucation.com/viewtopic.php?t=21427

With this proxy.rb you can (un)change a component into a proxylike bounding box. Its very handy. You can do multiple components with one click.
You do not need the hassle of naming proxies and their equivalents properly. proxy.rb does this for you.

The problem is that with the current plugins the proxy naming is the other way round. So the proxy.rb does not work with the Maxwel plugin but that should be easy to fix. I found it always confusing the way the Maxwell plugin worked since you had to rename the original component into a proxy. I needed to reread the manual each time I used proxy's.

Hope you you can do something with this JD,
Francois

[Half Life]

Hey Francois,

I think this is exactly the "indiscoverable hack" JD was talking about -- even the guy who wrote the plugin you linked admits that Google has made it difficult to have a stable plugin with that functionality.

Seems to me the best way to handle this is to use it sort of like material assignment -- select a component in the Sketchup model and have an option in the "context click" menu to link it to a high-rez MXS somewhere on your computer... which you would then have the option to have "automatically" replaced at export.

This way the user can control how much detail they want in their low-rez proxy stand in. Probably best if there was also some sort of proxy "material" (maybe neutral grey, like Maxwell default material) also assigned when you assign the link so the user can quickly identify the proxy objects in a scene.

Of course with the new ability to export hidden layers and to export just selected groups/ components it does seems the need for proxy objects is greatly reduced.

Certainly if it is going to create a significant delay in getting the already great sounding plugin in our hands I think I would simply choose to work around the lack of Proxy with the new tools.

Thank-you so much for listening to us JD!

Best,
Jason.

[fv]

Obviously any kind of component replacement by mxs components or instances would be better.

But I find it hard to believe that _proxy as its done by the proxy.rb is such an extreme wish to have or that it should be seen as an indiscoverable hack. There are many ways to simplify a model into basic geometry representing more refined. This is just one of them and one that will be used in a "pro" workflow anyhow. Rendering with Maxwell is such a typical "pro" need.

The good thing about proxy.rb is that you do not need to mind name giving. Its a simple automated command.
And you can quickly reverse the proxy which is not possible with the Maxwell version of the proxy.

If it would take weeks to program en debug the plugin in combination with the proxy.rb in a Maxwell workflow I would as well say the heck with it..
If its a matter of hours or a day or so I would be very happy with it and using it in almost every project.
Francois

[Richard]

Got to say to all, some great discussion here in all regards!

The one thing that stands up again is the MXS proxy! The one problem with any SU internal proxies is still that they must be a skippy file! Hence bought into SU at some point - I can tell you now (please someone tell me tip otherwise) it is near impossible to bring one good Onyx / Xfrog or other geo style tree into SU and map correctly for one, then just forever hope you don't unhide, turn on or anything else that may expose the high poly to the render engine or games over!

@JD mate just thinking is their anyway to have an initial window, popup, instruction etc just something that can be "never show again" checked, either just a message or a short animated gif of simply whats meant? - "TO BE REGISTERED AT CORRECT SCALE ON EXPORT, MATERIALS THAT RELY ON SCALE NEED TO BE REPRESENTED VIA MAP PLACEMENT IN SKETCHUP OR SCALED MANUALLY THROUGH MAXWELL STUDIO - SEE TUTORIALS FOR MORE INFORMATION" - it may sound weird but this will always be the number 1 issue with people ever using this link! It is always a persons opening question on any forum and hell knows how many took a while to get it and possibly how many may have just given up! So So many people will try maxwell via no manual or at least an "open and try" situation first and if this simple rule is applied 99% of the time if they have got that far they will get (with AGS for trans substitute) out of the box a good result!

[JDHill]

Actually, that will be unnecessary in many cases, Richard. Here is the reason why:

• - if an entity has UVs (i.e. if it has a texture assigned) from SketchUp, they are used by default
  - if it does not, then a camera-oriented 12" x 12" planar UV mapping is generated by the plugin

Optionally, in the right-click menu (this applies to groups or components, not individual faces) you will find a 'UV Override' item, from which you can choose one of the following:

• Default
• Camera
• Planar
• Cubic
• Spherical

Default means: either use the supplied SketchUp UVs, or generate the above-mentioned camera mapping -- this is, perhaps obviously, the default for entities which do not have one of the other overrides checked. When one of the others is checked, the results will be:

• Camera: generate the 12" x 12" camera mapping
  Planar: generate a planar UV mapping; this is always projected downward, using 12" x 12" tile size
  Cubic: similar to Planar, but with six sides; tiles are also 12" x 12" here
  Spherical: generate a spherical mapping

To begin with, there will be no control over the size or position of these mappings (they are primarily included for the case where we need UVs and SketchUp is not giving us any), and there is obviously no way to preview them in the SketchUp viewport. When one of these is selected, it will override any SketchUp-supplied UVs, so for example, where you have a sphere that cannot be mapped nicely in SketchUp, the Spherical override will work much better. These mappings are always centered on the entity they are generated for, and follow the transformation of that entity (with the obvious exception of Camera); so, if you have a brick wall component which uses the Cubic mapping, and that wall is rotated, the mapping will be rotated with the wall. Since their size is globally-constant (a.k.a. Real Scale), they will be good for architectural work -- control over the mapping size, however, requires some sort of specialized UI and will have to come later on as the feature matures.

[JDHill]

A quick example:

SU viewport:



Default:



Cubic & Spherical:

[fv]

Richard, I use a lot of the Evermotion trees, but never bring them in SU. If even one component can already stall SU for a visual I would not bring it in SU. I am now rather handy in Studio moving around instances to get a lot of green stuff in my scenes.

But I would say that the option you have with proxy.rb, your chances of unhiding the tree by accident is much less then when you put things you never want to see again in hidden layers.

Maybe JD can have a final word on the proxy's. Would it be possible to do a proxy the way proxy.rb does it ? I prefer it much over de Maxwell way were you have to remember names and can not convert a proxy to its original that easy.

Francois

[JDHill]

Well, I'm looking into it, Francois (you posted about proxy.rb just a few hours ago), but I don't have any concrete answers yet. Just assume that I'll let you know when I know.