[JDHill]

Right now, no, because I only show the menu when groups/components are selected. I'll see about changing it, but I'd think it's pretty rare to have much geometry that is not part of some group or component.

[Richard]

Only mate that some groups and components can get mapping issues if not exploded!

[JDHill]

Can you send me a .skp where that's the case? It should not happen with the new plugin.

[fv]

A simple straightforward way to assign the SU material "wood" to "burnished_lacquered_bubinga.mxm" is important of course, especially when rendering straight out of SU. But I will give up on Maxwell the day I have to mess again with mxm names and their proper spellings in SU. AutoMXM caused so much problems that most of my time went into debugging models to get autoMXM to work. It made me feel Maxwell was crap all together.
Imagine the hassle to work with models made by several people and combined with 3D warehouse parts. Why would anyone seriously consider all the hassle to rename SU materials especially with the slow material panel (OSX).

I liked the way Skindigo just assigned materials to their SU Material equivalents by going through a pulldown table of materials. MXMexporter also made things a little easier. But since the plugin for version 2 wasn't working for me I decided to always use Studio making assigning materials a piece of cake.

Richard, I know about paste in place but because of a bug in either SU or Studio a blanc SU file, even when geometry is pasted in place does not keep its origin in Studio. I can only use the original file to export from, any copied and pasted in place geometry from other files is misplaced in Studio. To keep a blanc copy around for export of parts of the geometry is too much of a hassle. I think the bug is caused as soon as you change the direction of axis in SU.

Francois

[fv]

Richard is right about SU having problems with mappings. Grouped geometry is mapped differently than exploded geometry. You see the change happen when you either group or explode, mappings are repositioned.

Reading Richards reply again, I see that he probably means the mapping issues happening at export.

Francois

[JDHill]

Yes, I think he's referring to the fact that the current plugin doesn't handle UVs correctly when assigned to layer materials, or for materials assigned to groups/components.

You should find it easier to manage materials in the new plugin. As per some of the previous discussion, I have added in the auto mxm capability again, but since you appear to dislike it so much, I think I should put in an enable/disable switch, so that it cannot affect your scenes by accident.

Regarding your comments about materials in general, the new plugin is very flexible:

1. it will automatically create materials, by default. Obviously, there is not much to work with, but it does infer whether to create an AGS or not, based on the opacity and HSL of the associated SU material. Clip-mapped materials (i.e. those which use alpha-based textures) are supported automatically.
2. you can select a material and edit various parameters; the interface for doing this is much simpler than MXED, and easily produces very nice materials with an absolute minimum of input. I expect this part of the system to be under the most active development after release -- I'll fine tune how it works based on your feedback.
3. if you need ultimate control, you can link to an MXM file. It is one click to edit the MXM in MXED if you wish to do so.

[numerobis]

1. it will automatically create materials, by default. Obviously, there is not much to work with, but it does infer whether to create an AGS or not, based on the opacity and HSL of the associated SU material. Clip-mapped materials (i.e. those which use alpha-based textures) are supported automatically.
2. you can select a material and edit various parameters; the interface for doing this is much simpler than MXED, and easily produces very nice materials with an absolute minimum of input. I expect this part of the system to be under the most active development after release -- I'll fine tune how it works based on your feedback.
3. if you need ultimate control, you can link to an MXM file. It is one click to edit the MXM in MXED if you wish to do so.

[fv]

I don't think anybody ever liked to manually copypaste mxm names into the slow SUmaterial panel.
The problem quickly raises its head when you import cars, trees, people etc from FormFonts, 3D warehouse and so on. Who knows what material names are there. I had models that stalled looking for imagemaps just because some imported car had a SU material name "white" found somewere on my harddisk in an obsolete mxm library as "white.mxm". AutoMXM made me have to check all material names in SU to make sure there wasn't an unwanted automated link present.

I remember many hours of debugging the materials and countless testrenders just to be able to render straight out of SU. Since I started using Studio I discovered that texturing a large model could be done in minutes. The less I need to work with the material panel in SU the better.

For me it would be ideal if I can just link a dozen or so SU materials to MXM's quickly without having to copypaste materialnames. This could be done by a table with left and right colomns showing the links. I would prefer the list to be so that only the links I choose are exported as links and the rest just as SU materials with or without some mxm-material properties in case of transparant materials.

The reason why the rb MXM-reporter became popular is because it could visulize all the different links to mxm's, automated or not, before rendering. It would be a bit of a dissappointment if we had to find someone to update mxm-reporter again to properly render straight from SU.

Materializing SU models is a bit different under OSX since the material panel under OSX does not list material names. This makes looking for and editing materials and their names a lot slower. Especially for OSX users mxm-reporter was a blessing.
Francois

[Richard]

Richard, I know about paste in place but because of a bug in either SU or Studio a blanc SU file, even when geometry is pasted in place does not keep its origin in Studio. I can only use the original file to export from, any copied and pasted in place geometry from other files is misplaced in Studio. To keep a blanc copy around for export of parts of the geometry is too much of a hassle. I think the bug is caused as soon as you change the direction of axis in SU.

Mate the issue of positioning between the two files for export of parts is overcome by the reproduction of the same file! I'm not at all suggesting the use of this method in opposition to JD implementation of your suggestion! It's perfect!

This is only suggested as a workaround for your current situation, I've been using this flow for the last month or so due to the problems I've been having and it is actually a breeze! Just a suggestion anyway!!

@JD

Can you send me a .skp where that's the case? It should not happen with the new plugin.

Mate I've exploded these files so as soon as it happens again I'll shoot through though here are two example tests, I've used skydome to ensure shadow cast doesn't hide the issues. The problems are self explanatory! The tiled roof house has SO MANY issues I haven't worried about marking all.

BTW I agree with Francois re AutoMXM though we are not all users - I can't tell you how many people have abviously tried it as what they see a prefered option for workflow and I've told to dump it. Then though that was due to the previous failings of the plugin and sure you will overcome those! So I do feel it is a worthy inclusion but yes PLEASE an on off switch like that in the 1.7 plgin!




Mate in regards to something ealier suggested regarding material assignment and the current MXED Browser, would i even be possible for a list view of SU materials to open in a window with the MXED in the same window and as shown here (SU material browser against MXED browser) both clickable and then assign material button which copies link and applies to SU material?

[Richard]

Materializing SU models is a bit different under OSX since the material panel under OSX does not list material names. This makes looking for and editing materials and their names a lot slower. Especially for OSX users mxm-reporter was a blessing.

Mate does the OXS allow you to select the option to list the materials by name in the browser drop down options in SU? On PC one must still select this option to see material names!

[JDHill]

I can't really do anything like that, Richard, but it will be a very simple process to create a material from an existing MXM file: one click (on a toolbar button) to open the MXED browser, and then a double-click on an MXM file in the browser to do the import. I can't really comment on the images you posted without seeing a file; I'm not seeing issues like that here, but if you have a file I can test with, I'd like to confirm that there isn't some issue I've not yet identified.

[Richard]

wow even thats great news mate! I'll try and generate on the other issue!

[brodie_geers]

Just wanted to throw in that I, too, am really excited about the 'export selected' feature. That's a biggie for me too. Should help out a lot, although, with the features you've been adding and the much quicker export times, I suspect I'll be doing a lot less work in studio than before. I think the only thing that may be left is the one thing I'm not sure you can fix which is high poly cars and trees.

-Brodie

[JDHill]

It depends on what you mean by fix. If you mean somehow allowing SketchUp to handle more high-poly cars, then no, but if you mean dealing with them as best as possible from an exporting point of view, then yes -- if the car is a component, and if you use instances, then I guarantee that meshes for only one car will be exported, regardless how many copies of that component you make, or how you nest them in other components, etc., etc. If each instance has different materials, due to faces inheriting materials from their group or component, then the car will automatically be split up on material boundaries (if it's not already explicitly split up on faces) and instances of each material group will be generated.

There are other strategies we can explore later on, but none of them are very attractive. The old plugin has its 'proxy' feature, but you cannot visualize what you're going to get beforehand, and you suffer some of the same scene-debugging issues as with the auto-mxm discussion above. Richard has proposed a similar idea, a 'mxs proxy', but this is basically a different version of the same thing -- the data still has to come into memory at some point in time if we want to render it, and this is worse, because you're talking about trying to merge geometry and materials, etc., from different mxs files, and this is not a really simple thing to do.

In the Cinema plugin, I wrote a custom instance object from scratch, because the native so-called 'instance object' in Cinema was of a poor design and didn't save any memory at all. So, mine just drew bounding boxes to show where the instances would end up, since the Cinema SDK allows for doing that, and it worked very well; we could build scenes with millions of instances of things with very good viewport performance. But -- all the work was for nothing...at the next half-point version update of Cinema, they finally 'fixed' their own instance object (after however many years), rendering my own completely superfluous.

[numerobis]

If you mean somehow allowing SketchUp to handle more high-poly cars...

Yes, please! Do it!!!