Import/Export Color Management issue

[detbear]

The obj files don't transfer group data. Needs to be 3DS

 

Doesn't look like the whole model transferred. missing two sides.

[robcat2075]

When you reload that OBJ you made, the groups come in correctly colored and named, right?

[detbear]

As far as I can tell....yes.

[detbear]

Here's a screen capture.

 

[robcat2075]

Now we can put two files that should be the same thing side-by-side and see what is different and if it's important.

There's a lot that is different.

 

First possible clue... A:M doesn't handle names with spaces when it's trying to import and OBJ file.

 

 

[detbear]

Do you think it is the same case with .3DS exports. Those carry the color info. OBJ does not. Even from Blender as I said above.

[robcat2075]

I don't know if it is or isn't about spaces in 3DS.

 

OBJ models DO have color. It's stored in the companion MTL file

 

 

 

I do know that if i try to import "Cube creation Y&G.obj" to A:M I get the shape but no colors and no groups.

 

If I remove the spaces from the file names AND from the references to those names INSIDE the files, A:M loads the OBJ and the groups with color. The Groups just have numbers without names but at least they are groups.


First lesson: Don't make anything at any step of the process with a space in a name (even if it's a group name) and for now... don't use more than 8 characters while you are doing tests.

 

I also just noticed that the ampersand (&) is trouble. Just use letters and numbers in your names for now

 

I will get Blender and see if there are any obvious fixes.

 

This is your blender model after I deleted all the spaces in the file names. It came in with groups and colors.

 

[robcat2075]

Here is my test model made with groups in A:M and exported to OBJ.

 

TestCyl2.zip

 

 

When I import that in Blender it has colors. I don't know how to see Groups in Blender but they must be there too.

 

Now... why is it that when you import an OBJ from A:M you don't get any colors or groups?

 

[detbear]

That's my question. I have no idea. Did you use materials or just add color to the groups.

[robcat2075]

Does that testCyl2.OBJ load with color for you?

 

That's my question. I have no idea. Did you use materials or just add color to the groups.

 

All i did was change the color chip in the Surface Properties of the Group and named the Group.

 

No materials. You don't need A:M materials anyway if you have to re texture it all in Lumion, right? You just want Groups, right?

[Rodney]

A:M's materials would need to be baked into a decal image as things currently stand.

 

To 'connect' materials in A:M and some other program equivalents would need to be found.

The latest PBR approach is much closer to A:M's material approach in that under the hood its the same material.

So... if a direct equivalency is needed then similarly to Robert's comparison of text file differences a similar approach could be used to compare 'empty' materials in whatever two programs were being used. This basic material would then make the transfer from one program to another but the additional materials would be replaced on a material by material basis.

 

A utility could be created that would automate assignments so that materials in one program would automatically change materials in the other.

The idea would be to create two directories, one for each program and the utility would manage the equivalencies... changing them as needed based on user input.

 

I may have to test that idea on a simpler problem.

The basic idea is that the middleman utility doesn't particular care what the file is, what format or even the content..

It just needs to know what the user considers to be equivalent.

[robcat2075]

Try opening this OBJ in Blender. This was exported from an A:M model that had a simple material on each Group.

 

TestCyl3.zip

 

When I import it in Blender the top is Red and the bottom is Green. Where do i look for "Groups" in Blender

[detbear]

I get that result as well in blender but not in Lumion. When I export the minifig into Blender it comes up with colors. I went back and shorted the names

as well as removing the decals. But straight from A:M to Lumion doesn't work out very well. I could go through Blender but that would take forever.

[robcat2075]

Import this into Lumion and tell me what you get

 

TestCyl5.zip

[pixelplucker]

I don't think AM renders using an ICC profile as many desktop publishing and photo editing programs do so it shouldn't have a reduced color range when rendering. As far as dynamic range the purpose of color profiles is to restrict the visual representation (what you see on screen) as accurately as possible based on target output. Typically in my 30+ years of color separation and color correction work, ICC profiles pose more problems than they are worth unless your a publisher with a set output (printing presses) that never change. Often the majority of users have the wrong profile, old profile, uncalibrated monitor, wrong gamut setting, and or wrong target printer and the applications often embed the wrong color correction to the final output resulting in washed or overly saturated images when printed.

 

There used to be a profile print called an IT8 that came along with a digital jpg of the same file that you can use for calibrating visually. Surprisingly this old school method yields the best generic calibration of what you see on screen with the real world.

 

Note that this profile I also have the hard copy to go with it.

Other methods are color monkeys and other digital calibration devices but the downside of those is they basically create an ICC profile. Many new monitors adjust their brightness depending on ambient conditions of the room. So I don't think they would be very dependable.

[largento]

Just playing around to see what I could do via A:M and Photoshop.

 

Here's one of your images. I took it into Photoshop and did a few things. The great thing is that you can bring in an image sequence in Photoshop and apply these changes (non permanently) to the whole video rather than having to do a frame at a time.

 

 

There are lots of LUTs out there that you can use to achieve different looks. I bought a bunch during a sale at Film Riot and they are named for the various movies they try to emulate.

 

Here's another test. I created a material from that concrete image you mentioned and used it to color the mini-figure. I also attached an environment map texture (the model doesn't have any specularity settings.) The top is how I rendered it and the bottom after I played with it to try to make it look like it was on film. Bear in mind, I think everything should look like it was filmed in 1966, so that influences what I do. :-) You can experiment endlessly with what you're doing in Photoshop to get the look you like.

 

 

I'm just offering up that post-effects may help you to achieve what you're looking for.

[detbear]

Import this into Lumion and tell me what you get

 

TestCyl5.zip

 

It comes through culled really bad. It does have the two colors. That's probably because your model doesn't have enough geometry. When I try it with a more complexed model....say the minifig. It doesn't work.

Still has one solid color. No matter how simple or short the names are. I have no spaces in them.

 

Even if you can get that to work, an obj isn't going to transfer Mapping along with it for stamps.

[detbear]

I think if you added a few more splines it would not cull in lumion.

[robcat2075]

These problems aren't solved by loading a complex model and finding that it doesn't work. You start with a very simple model and try small changes until it does work

 

It has color? That is success. That's all I needed to work. Now I can go on to the next step.

That was an A:M OBJ with a Blender MTL.

 

All we have to do now is find out what is the key difference that stops the A:M MTL from being used.

 

There's probably just one line in this that is the problem...

 

[detbear]

I wish I knew more about coding. I'm afraid I'm not much help.....

 

 

I did have this thought.....The models in A:M default to that yellow color. underneath when you select a model.

 

You know what I'm talking about......I wonder if that could somehow over-ride group colors. Like I said, I know very little about this.

[robcat2075]

What about groups? Do you have any identification of Groups on that model when it's in Lumion?

 

 

 

[detbear]

Too bad the guy who created this exporter isn't still around. He could probably fix it for Lumion.

[detbear]

Yes. When you hold your cursor over the color groups, the names of the groups appear.

 

[robcat2075]

Yes. When you hold your cursor over the color groups, the names of the groups appear.

 

color names.jpg

 

 

That is also success.

 

If you turn that so the other side is facing the camera does the other side become visible?

[detbear]

This is my own model straight from AM.

 

 

 

 

The group names show up when I hold the cursor over them.

 

I notice that if you add spline rings and add them to a group, it messes it up. You need to erase the group and create a new one including the new mesh.

 

ALSO....LUMION hates open holes...so I made that shape enclosed.

[robcat2075]

This is my own model straight from AM.

 

am export obj.jpg

 

 

 

The group names show up when I hold the cursor over them.

 

 

I'm lost.

 

Not getting groups from A:M was the problem that had to be solved but the groups have been coming through all along?

 

What is the problem we are trying to solve?

[detbear]

This is what happens when i bring the minifig into lumion from A:M

 

 

 

One of the groups dominates a larger area than it was assigned to. Also other areas are not right either.

 

A simple model works. The minifig does not.

[detbear]

So for some reason, more complexity isn't placing the groups correctly.

[robcat2075]

We need to Skype about this. There is too much getting lost on the forum here.

[jalih]

I have no big problems with AM OBJ export. Sometimes there are some missing faces and texture maps have to be adjusted before rendering.

 

Attached are two test renders using Sitex Air. Both models are exported from AM as OBJ and imported into AIR Space. I only had to fix the texture mapping of the lego models face before rendering.

 

[detbear]

It doesn't work in Lumion. So that doesn't help me.

[robcat2075]

I only had to fix the texture mapping of the lego models face before rendering.

 

 

Hi Jalih!

 

Tell us more about this step. What did you have to do?

[jalih]

 

I only had to fix the texture mapping of the lego models face before rendering.

 

 

Hi Jalih!

 

Tell us more about this step. What did you have to do?

 

Nothing fancy, just deleted the imported color map that looked wrong and loaded the original png file from AM project. Then it was just a matter of scaling, positioning the texture and changing the color of the face material to be same as the rest of the head.

[Rodney]

Kevin,

Are you setting *any* surface color in the Models color setting? As opposed to setting them in groups.

If you are... don't do that. Edit your surfaces in the Group settings. Leave the defaults underneath alone.

 

Also before exporting are you doubly checking to make sure all the normals are facing outward?

 

Those two things could very well lead to the results you are experiencing.

 

 

 

Jalih,

Thanks for the insight into Sitex Air. I posted here in the forum about that suite some time back and took a quick look into it. Sadly, I didn't get much further than that. I'm glad to see you did!

[robcat2075]

 

 

I only had to fix the texture mapping of the lego models face before rendering.

 

 

Hi Jalih!

 

Tell us more about this step. What did you have to do?

 

Nothing fancy, just deleted the imported color map that looked wrong and loaded the original png file from AM project. Then it was just a matter of scaling, positioning the texture and changing the color of the face material to be same as the rest of the head.

 

 

I think the problem for Kevin is that Lumion has no model editing capability. It's just a renderer. Everything has to work from imports.

[Rodney]

the problem for Kevin is that Lumion has no model editing capability. It's just a renderer. Everything has to work from imports.

 

Agreed. There has to be a middleman program in the mix here.

That could be a plugin but it could be a number of other things.

 

Troubleshooting-wise, it is vitally important to make sure what is being taken out of A:M isn't compromised in some way. A:M may be coded to deal gracefully with something but other programs may not. As we are talking about a lossy conversion process, in the process of exporting to OBJ the exporter will just push any problems on down the line. So if normals are facing the wrong way... the exporter can't know that easily (unless it has been programmed specifically to catch those abnormalities.

 

So... should a user decide to export for use in other programs inspection of the model in A:M is most definitely required. There will be errors and omissions at this stage of the process.

 

The middleman software (or exporter) is the next point of failure to examine for obvious reasons. It has to read, interpret and write the data. There will be errors in the transaction and hopefully there will be tests that correct errors and ommissions from the first stage of the process. For instance, the code might be able to 'fix' an inverted normal based on patterns. If everything normal surrounding it facing the other way then turn that sucker around. But most basic exporters very likely do not test for such things so those fixes need to be made before the exporter takes over the process.

 

The importer of the target application works with what it has. The primary way to test success here is to determine what success looks like by using a successful exemplar.

 

All this suggest to me that the problem most likely to resolve the issue is with the model in A:M itself.

This has been demonstrated several times in this topic; names with spaces, odd filenames... garbage in garbage out.

 

Focus on the model in A:M first, simplify the tests in order to demonstrate a successful pipeline.

Then consider other problems.

Lumion apparently cannot edit models.

A:M can edit models.

 

Largely what you are already doing now.

[detbear]

I've tried all those things in tweaking the groups, but none of it has worked so far.

[Rodney]

I've tried all those things in tweaking the groups, but none of it has worked so far.

Perhaps you can attach test files in the first post of this topic.

I'd like to look at that exact same 'minifig' model you state is problematic in Lumion.

 

I note that 'Model and material variation options', whatever that is, are only available in Lumion Pro.

Not sure which version you have.

[robcat2075]

Kevin, This zip has 8 progressively different OBJs in it.

 

TestCyls.zip

 

Load each one into Lumion and tell me when the first one is that comes in with colors and Group names.

[jalih]

Just downloaded trial version of Lumion and tested OBJ import. It seems that if you delete decals from model before exporting, then material groups are working fine inside Lumion. Bad news is that you probably have to do some texturing work inside some other program.

Edited January 24, 2018 by jalih

[pixelplucker]

Not for nothing but I remember textures on obj's not looking as vivid when imported into or exported out from AM using the mtl files and as I remember correctly I would re-assign the textures and basically junk the mtl file.

 

My hunch is the obj i/o might need to be updated if possible?

I'm back using 15 (cd version) here because I hop between machines and sub would only be tied to 1 machine.