[messire]

Stefan,
Welcome to the club of beta testers!
Francois, Sheik, Richard and I are among the oldest SU users out there working with MR..
We've been at it since the first plug in with early beta, and things have improved lots, but still basic problems occur in simple tasks, due to the fact that each new version adds its quantities of novelties to deal with....frankly i'd prefer a flawless exporter with little options than a complex multi option stuff that is not useable...
To be dealt with:
- export speed ( main issue now) with automxm
- shadows / time ( should be wysiwyg between Su and MR) ( now the image size is right thank god no more cinema add on needed)
- texture library simplification...i personnaly never create a MR material within SU, but i'm always loosing precious minutes recreating the SU counterpart ( making jpg around 200 k for thumb/display view in SU), importing that image, naming the SU material with same name as the mxm etc...)...Who creates MR materials in SU? anyone? As we exchanged with pavol, a neat option would be to be able to browse in SU the mxm folders and load automatically 1 or a folder of textures in SU, converting the main jpgs, naming the SU material created etc...)...

Nils

[fv]

Hi stefan,
Just an idea, I can't see your files to download but I think it has something to do with your unit precision preferences.
I don't have any problem grouping or ungrouping so far with my renders.

Anyone here on Snow Leopard to test the new plugin for auoMXM.

Francois

[fv]

HI Nils,
Have you tried lately to make the jpg images in SU and MXed the same size. I have noticed that because of speed improvements on several levels the need for making specific SU jpg's for textures is only needed in very specific cases. I just did a rendering with detailed masonry and the result came out as good with SU sized textured as it did with Maxwell larger sized textures.

As far as a huge timesafer is concerned. I would really like it if I can link predefined mxed materials from a puldown list and connect them to SU materials from a pulldown list almost like Skindigo does it. I totally agree that there is no need to further tweek materials in SU other than what SU has to offer. This way you can easily assign materials in any SU file without having to bother edeting SU material names.
In short, if the material "wood" in SU could be assigned to "zebrano_5498.mxm" it would be perfect if this could be done by a list that can be edited and maintained. Quick and easy. If I decided that the SU material name "wood 02" is also going to be asigned to "zebrano_5498.mxm" it should also be possible. The plugin now does connect mxm names to SU names but its through a material panel. That panel is the weirdest panel ever made as a SU ad on. Not at all transparent of what you are actually doing. Its also in conflict with other texture settings.

It should work like a little datebase like Filemaker records. If you want to add another material assignment you just add one to the list in front of you. If you just assign one mxm material to a few SU materials than thats it. The rest of the unasigned materials should be converted as they do now without any further hassle. This way you only have to work on the assigned mxm materials. As an extra you might add some reflectivity or emitter values to an SU material but in the most simple of ways with a slider or something. Not by having to choose between plastic or metal. You need a lot of testing to understand the difference between those 2 and by than you would have used a proper mxm material to converto to.

The whole material assigning proces in most of my renderings and models should take no more than minutes as opposed to many hours or more as it is now. in Skindigo it takes so little time to texture a model that those who use it do not even mention it as an issue. Some Skindigo users who also own Maxwell licenses report no longer to use Maxell just because of the ineffective and tedious texturing proces. Even today after many projects I still don't know if .mxm needs to be added to a SU name to convert properly. Sometimes it does and sometimes it does not.

[JDHill]

The SketchUp file is available in the thread above (just before the first image).

Ack, I downloaded both of the mxs, but skimmed over that link. Thanks.


As for the rest of these posts, keep on writing - I am always taking note of what you say. I don't believe in user-defined development, but there is no doubt that many aspects of my other plugins came directly from conversations which took place on this forum.

[messire]

HI Nils,
Have you tried lately to make the jpg images in SU and MXed the same size. I have noticed that because of speed improvements on several levels the need for making specific SU jpg's for textures is only needed in very specific cases. I just did a rendering with detailed masonry and the result came out as good with SU sized textured as it did with Maxwell larger sized textures.

Francois,
The issue is not really an MR bug but a SU texture library limitation: it gets soooo slow to open, switch between materials ( concrete to wood etc) when the related textures are over 200 kb, that i made ( since the first day) all my SU jpg's much smaller than the lets say arroway originals ( which i even downsided before using them in MR)..so basically when i use Wood 38 from arroway, I use a 1.8-2.0 mb jpg file as reflectance ( as well as other S and B textures in the same downsided sizes), then, i take the same reflectance file and save it as SU jpg at a max of 200 kb ( downsizing image menu + 8 jpg compression)...ANd still the SU material menu is slow as hell on a very fast machine ( this is really weird btw...) with around 40-60 materials per library at the big max...
It means the biggest flaw of the SU material system is to work with the actual image size instead of linking to it...

JD: i agree users should not dictate how a software should work, lets just say we are using SU because its simple, efficient, quick, and very architect friendly despite limits, and we wish our rendering software was embeded simply in the SU interface... This does not means options should not be available, and more possibilities given, but it means KIS ( keep it simple)... I've seen other plug ins and man it feels we ( SU users) are in middle ages in terms of efficiency with MR plug...

Nils

[Richard]

Richard, I would like to read your thread about the different time-settings! What should I search for?
I just never thought changing the SYSTEM TIME on my computer (in the lower right corner, you know) one month backwards would cause the shadows in my software apps to change... Scary
So the next 6 months I must avoid strange shadow results in a different way than I used to?
/Stefan

Mate here is the post from another thread! Just a point on the sun location between SU, direct export and export from studio where each renders a different sun location!

7. Currently sun setting from SU>MR are seemingly an hour out (not tested accurately) this could account for daylight savings I guess. Though even in the default boulder Colorado location when exported to MR the sun location is incorrect. Furthermore when the exported MXS is opened in studio the sun location is completely lost – this one I really don’t understand???

[Richard]

Have you tried lately to make the jpg images in SU and MXed the same size. I have noticed that because of speed improvements on several levels the need for making specific SU jpg's for textures is only needed in very specific cases. I just did a rendering with detailed masonry and the result came out as good with SU sized textured as it did with Maxwell larger sized textures.

Mate I think for most users the issue isn't so much the issue of texture size from SU though I know the maps I generally use in maxwell would blow SU out of the water speed wise! They certainly have reduced the issue of naving with large maps though the material browser opening on each material sample is where the time is lost with large textures.

I generally either use a reduced res image or just the b/w bump map for texturing!

BTW I think the SU users who have switched from MR to Indigo have done more so due to the option of a very simply material editor option. As far as texture linking though I'm not sure I really note any differences in the two plugins! Certainly when it comes to material editing and preview I do certainly note many differences and not any that I would say good to be honest!

[fv]

1. There must be a bug in the new plugin that explains why you can export a model in about 10 seconds with 2.2 were it exports with 2.4 in more then 10 minutes. Larger files could take hours were with 2.2 it might be a minute.

2. Skindigo took assinging Indigo materials away from the SU material panel and that is a very good decision. The less you have to click and edit in the SU (edit)material panel the better. I now have to edit each material and tediously have to copy/paste mxm names. If I need to assign one mxm to multiple SU materials I need to duplicate the mxm and rename. I do this for instance in case I seperate SU materials for later alternative material proposals.

Actually, assigning materials in Studio is a snap, a nice list and proper drag and drop functionality. Sometimes I think I will just model in SU and assign the whole lot in Studio. But while modeling its very handy to now and then throw out a Maxwell rendering. Goin to Studio each time and assign again is not an option.

I wonder how many hours are really spent on the plugin, I sometimes feel its decades work for a monk and eveytime he looks up SU or the OS has upgraded just to start all over again....

[messire]

last thing: ( sorry its a bit off topic)

JD: I think at some point you should set a meeting with the NL staff and tell them that SU is going to be leading the 3D world within a few years: reason is simple: Google knows 3D is the future of every virtual life that is going to be created, and this is the reason of the developpement of 3D wharehouse, buying sketchup etc....and beeing the power company it is, they will push it with all means)
I think it would be a very big tactical mistake to underestimate Sketchup and Google's developpement of it by not putting huge powers behind developping the best third party render engine for it: If NL was my company, I'd make sure SU would get the max dev power for the MR plugin.

Because today is pro 3D times still, but soon a new breed of 3D users will come out, starting at 6-7 years old and willing to use a simple tool as SU to modelize their virtual world....so today you are filling the needs of hardcores 3DS max users, but soon they will be in so small numbers compare to SU users it will be neglictable as a consumer base...

my 2 cts

Nils

[stefan_kaplan]

Currently sun setting from SU>MR are seemingly an hour out

Richard, the sun setting from SU>MR is an hour out when your SYSTEM TIME is different from the "SketchUp-time".
The next six months, from October 25th 2009 until March 28th 2010, we can only render winter scenes if we want to get a WYSIWYG-result.

I made a little test:


So when your sytem-time and SketchUp-time are BOTH SET TO THE SAME (winter-time or summer-time), you get the right WYSIWYG result!

This has to be changed. Why would the exporter ever look at the system time? I don't get that.

/Stefan

[fv]

Hi Nils,
tx for your off topic comments on the power of SU. I am sure you want to kickstart the work on the plugin for SU. I am with you on this.
Francois

[Richard]

Stefan

Mate that is a great test and great find!! I'd never have thought to check against pc time! Certainly weird! Great to know that setting pc time against SU time will fix the problem for now! Though one then will have problems finding date modified files though!

Would be interesting if when in studio the same fix works! I used to use the globe positioning in studio once there to fix the sun location to close to where I wanted it but now in V2 (yet to upgrade BTW) rotating the glode is worthless as it sticks the sun to the same time you have set so even that now is a worthless option. Not sure why they changed that as now it just seems an unusable functionality except that you get to spin a little globe which can be fun, just doesn't do anything!

[fv]

Working on my current project I decided no longer to rely on 2.4, slow or not. autoMXM has no predictable outcome. I just export using 2.2 and assign my materials in Studio. Amazing that I could spent hours to get just one material assigned properly without any clue why it does not convert while in Studio just manually one can assign one material per 10 seconds. I just select the geometry by selecting the appropriate SU material and then apply the imported mxm material to that selection. A few mouseclicks. All in all less than 5 minutes work. Its just tedious to do when you are modeling in SU and want a lot preview renderings, I don't like to assign all the time in Studio. So, autoMXM is an important part of the plugin.

I really wonder why this very simple routine works perfectly in Studio manually and by autoMXM on export the wrong materials are assigned, or totally not or partly or the whole proces fails because the default material needs unchecking its non existent imagemap. I think it would be a big improvement if autoMXM ONLY looks into the choosen folder and its sub folders as its supposed to do instead of checking the whole disk for possible matches in material names. That way I would be sure it only checks the project library (about 10 carefuly tuned MXM materials) instead of my complete library (hundreds of materials). As I understand autoMXM keeps looking for materials if it can not find the name in the choosen folder at export.

Francois

[stefan_kaplan]

JD, in another thread you asked:

...what would be useful to me would be a very specific list of what you absolutely need fixed in the current plugin.

Many requests on improvements to the plugin have been posted, all of which are important, but we've been getting by without them so far.
The only REAL STEPBACK is the infunctionality of the AutoMXM-feature.
I don't use AutoMXM myself, but I think fixing something that used to work should be the number one priority!

/ Stefan

[Richard]

JD, in another thread you asked:

...what would be useful to me would be a very specific list of what you absolutely need fixed in the current plugin.

Many requests on improvements to the plugin have been posted, all of which are important, but we've been getting by without them so far.
The only REAL STEPBACK is the infunctionality of the AutoMXM-feature.
I don't use AutoMXM myself, but I think fixing something that used to work should be the number one priority!

/ Stefan

Perfectly said! Return of existing functionality is first priority for those who use it!

A point I guess to be considered - maybe VodkaMartini might not mine the use of his ruby! Maybe a deal? And if the option through that was added to make a link set back to SU the name of the MXM (then either auto to a SU material library or user saved) this could set those materials as auto in future! So it works both ways and sets very simple workflow for all users through one material selection panel so base is understood!

I think I just thought of a very simple and yet expandable material panel! I'll work up a graphic soon!