[messire]

Hi all
Got an issue since upgraded to SU 7.01 ( french no 7.1 available now) with MR 2.0 / skp2mxs 2.4 plugin

Got a 3D model with 54366 lines and 22558 faces ( not that big)
model in SU is about 5.5 mb
http://dl.getdropbox.com/u/2095112/test%20SU-MR.skp

OSX 10.5.8
Nehalem dual Quad 2.26 with 16 GB ram

this file does not export at all, it launches export menu, then stalls at the beginning of the progress bar...

Is there anything i'm doing wrong?
thnx
Nils

[messire]

1st discovery
I read FV's post so tried by unchecking automxm
file exports that way, really strange because the file has NO textures...( only white faces..)

and:
since i ONLY work with automxm, it would turn my SU>MR dialog totally useless....
please someone fix that! otherwise its just...well..the end of the game!

Nils

pS: i feel beeing a guinea pig alpha tester with this since the beta version grrrrr

[JDHill]

This model exports fine here (on Snow Leopard & SU 7.1), regardless of Auto MXM being enabled or not. I don't have a copy of SU 7.01 - maybe someone can confirm whether there's an issue here related to that version, or if it's something else in your setup.

[fv]

Hi Nils,
that's exactly what happened to me as well, OSX 10.5.8, latest updated version and SU version 7.1.4870.
If you turn off autoMXM, export is fine. When I started a new model the export runs ok but slow. My older models start to export but then at the start of the export they stall endlessly. Some models start very slowly to export but its actually useless to wait for the export to finish. You can however use the old plugin and open the exportfile in the new Studio and work from there. Not a fast way to do quick previews but at least you can render in v2.


Tx Nils to confirm my problem. I am afraid we are the only 2 SU-Maxwellers on OSX.

JD, its a problem with the new plugin since the old plugin works fine. I don't think suddenly all OSX systems have become buggy at the exact moment the new 2.4 plugin was released by NL. We have several differently set up OSX systems and the same problem repeats itself. Maybe under Snow Leopard it works fine but not under 10.5.8 Since our other CAD systems are not Snow Leopard compatible we can not update to Snow yet.

Francois

[messire]

My older models start to export but then at the start of the export they stall endlessly.
Francois

exactly what happens with this model and any model i'm working with...this is driving me nuts grrrrr
JD: please find where the issue is so Pavol can solve the issue with the plug in...

Francois: i'm not sure i understand the work around: shall i reinstall SU export 2.2 instead of 2.4?
thnx
Nils

[fv]

yes, just reinstall 2.2. Very simple proces if you still have the installer 2.2
You have to open the file in studio though since the old plugin does not start v2.

I am working on a new project now and as it is grwoing (now 4 Mb with about 10 textures 2.4 no longer exports properly. It takes too long. Lets say 10 minutes were 2.2 would take about 25 seconds.

I have a feeling that the exporter looks for the texturepath for every single face, so even with one texture it would take long..

Wish the plugin bugseekers luck...and hold your anger..

[fv]

Actually, when looking in Studio at my exported SU, autoMXM does not do much, just one material got autoMXMed but the others did not. And its not a naming issue. autoMXM with 2.4 does not work properly were 2.2 did. Not just a speed problem.

To be honest, I would advise not to update if you're on OSX and also want to use the new plugin 2.4

This is a typical problem because of the way the plugin is written. You have no idea how materials are converted since there is no visual on the process. It is absolutely necessary to provide for a editable conversion list of materials before export in a new plugin. The amount of trial and error needed to render files from SU to Maxwell is a waist of (my clients) time. Since the only thing you are really doing by trial and error is getting the proper textures on the geometry. With Maxwell it is a terribly clumsy process compared to for instance Skindigo were its actually a no issue at all.

JD, while working on the new plugin, imagine you need to texture dozens or maybe hundreds of grouped and individual parts of geometry and about 20 to 50 different materials. now imagine yourself test rendering all day just to get the SU names convert properly to mxed names. And even you are 100% sure the names are correct they still don't convert. The only way to see what is happening is to open each test file eacht time in Studio and check and recheck. The plugin MXMreporter was written by a user who understood directly how silly the Maxwell plugin was made and tried to help out. But the MXMreporter list can not be edited and the conversion still needs to be done by naming SU materials by their mxm equavalent. That means copy/pasting from the finder to SU and opening and editing each material in SU. The texturing workflow from SU to Maxwell feels and actually is very ineffecient.

[Richard]

Mate if you can use the MXMreporter why are you still hasseling with autoMXM - it has always been so error prone!

[stefan_kaplan]

As this is the "issue with SU export" thread I might as well post an ever lasting problem/error: Materials ON groups vs. Materials IN groups.
Ungrouped models have always seemed to render more flawless than models with groups.
Sometimes everyting works just fine and then sometimes errors occur.
Since grouping geometry is a fundmental part of the workflow in SketchUp, ungrouping before rendering is not a solution...

What I don't understand is why it still is interesting to see the render result when using groups (since beta-stage and uptill now in plugin v2.4)...

Here's an example with strange dark colors where the houses are still grouped:


And a much nicer result after ungrouping (exploding):


Someone might have discussed this issue before and there might be a simple solution to the problem. In that case, please tell me
If not then this ought to be fixed in mxs2skp v2.5

/Stefan

[fv]

never noticed this.
Have you checked this through Studio ?
Like changing materials in Studio for about the same colors and see what happens ?

It might be that some of my renderings have suffered by this effect but I have never tested it.
Tx for bringing this issue to the forum.

A bit off topic but SU 7.1 is a lot more responsive with large models with lots of repeating symbols, and v2 is also faster. All together I would appreciate a properly working SU-exporter even if only the autoMXM issue was solved temporarily before the new plugin would surface.

Francois

[Richard]

I think that may be a SU related issue that can occur with several exporters! A simple workaround is to copy your last component out of scene as it is generally the last component that tends to suffer from material breakup. Ever now and then you can see the effect in direct image export from SU!

[stefan_kaplan]

WHHOOOAA IT KEEPS GETTING WIERDER!

Have you checked this through Studio ?

Since I never use Studio ( ) I've uploaded a simplified and purged mxs file for you to open, if you don't mind It's in v2.
Thanks in advance, Francois.

EDIT: You can see that the darker faces looks darker in Studio but they have the same material as the normal faces...

Here is what the file looks like in SketchUp. On the left: A group. On the right: A copy of the group, exploded. Date in SketchUp is June 1st at 13 o'clock (the SketchUp model can be downloaded here):


This is what the rendering looks like, rendered today october 27th (the mxs-file can be downloaded here here):


I've encountered these strange dark faces from the very early stages of the Maxwell Plugin... Please make them go away.

Then I also realized that there was the daytime savings problem that I didn't seem to encounter earlier on in this rendering (shadows in maxwell didn't equal the shadows in SketchUp).
Even though this is a known issue in the exporter, I never really know when it appears. Sometimes the daytime savings won't affect my rendering and sometimes it will, and the shadows are wrong.
A couple of days ago "wintertime" started and we had to turn our clocks backwards one hour.
So I tried to turn my SYSTEM CLOCK backwards one month and this is the result, september 27th!!!(the mxs-file can be downloaded here here):


Shouldn't it be possible to counter-act this strange behavior in the next plugin?

The render result should be as close to the SketchUp-display as possible. That must be the goal with the plugin...

/Stefan

[JDHill]

If you inspect the pieces in Studio, you will clearly see that the dark areas are caused by poorly-aligned normals. I am definitely interested in finding out what the plugin can do about problems like this; in doing so, the mxs files are nice, but it would be much better if you could make the SU file available.

[Richard]

As I mentioned in another thread, there is SU time, SU direct to MR render time (generally 1 hour out) and then there is MR studio time (the above times shot out the window) - hence it is always necessary to relocate the global position and time once the export is opened in studio!

[stefan_kaplan]

...but it would be much better if you could make the SU file available.

The SketchUp file is available in the thread above (just before the first image).
The normals point in the same (positive, outward) direction inside the group as in the exploded group.
I don't use Studio and just expect the same result from grouped / ungrouped geometry.
Thank you for looking at it, JD.

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