[SOLVED] Odd discrepancy... A bug ?

[ajz3d]

Please, consider the following scenario.

In external application you create a model with 7 subobjects. Let's call them alphabetically:

- objectA,

- objectB, etc.

Some of those subobjects share materials:

- objectA, B, C and D share materialA

- objectE and F share materialB

- objectG has its own materialC.

1. If you import this .obj file to 3D Coat for laying out UVs, you get:

-

Materials

named:

->materialA - containing objects A-D,

->materialB - containing objects E-F,

->materialC - containing object G.

-

UV-sets named

:

->materialA - containing UVs of objects A-D,

->materialB - containing UVs of objects E-F,

->materialC - containing UVs of object G.

This is very convenient and I like it.

2. Let's see what happens if you import the same model to PPP. What you get is:

-

Materials

:

->materialA - containing objects A-D,

->materialB - containing objects E-F,

->materialC - containing object G.

-

Objects

:

->objectA,

->objectB,

(...)

->objectG.

So again, it's very convenient. You can hide, fill, etc. multiple subobjects sharing a certain material, but you can also do the same with individual subobjects.

3. When imported to Voxel Room, the model is separated into subobjects and each subobject receives its own layer. Perfect.

BUT...

4. If you import the model to Retopo Room, here things look a bit different.

-

Groups

:

->materialA - contains objects A-D,

->materialB - contains objects E-F,

->materialC - contains object G.

-

UV-sets

:

-> NO UV-SETS ARE CREATED!

This can be good or bad, depending on what you want to do.

If baking with names correspondence is your goal, than it's damn awful, because you now have to:

->create a

Group

for each subobject and name it correctly (using former subobject name that was lost when you imported the model to

Retopo Room

,

->move each subobject from a group that it shares with other subobjects, to its individual group you have just created.

->recreate UV-sets and move objects according to their former UV-set linkage.

Let's say, you're done with this additional work and are ready for baking with names correspondence selected. The result is:

5. Paint Room:

-

Materials

:

->objectA_materialA - contains objectA,

->objectB_materialA - contains objectB,

->objectC_materialA - contains objectC,

->objectD_materialA - contains objectD,

->objectE_materialB - contains objectE,

->objectF_materialB - contains objectF,

->objectG_materialC - contains objectG.

-

Objects

:

->objectA_objectB_objectC_objectD_objectE_objectF (a combination of all object names, up to 50 characters) - contains ALL SUBOBJECTS(!).

So it goes completely bananas here when compared to how it worked in point #2.

Is this behaviour intentional or is it a bug?

[ajz3d]

Let's return to point #4, after the additional work has already been done.

Let say you really want subobjects to have their own, individual Objects layers in the Paint Room and you want Materials to contain only three layers representing our original materials.

Use names correspondence in baking didn't produce the required results, so perhaps baking one subobject at a time will work.

You hide all retopo Groups and leave only one with the objectA (now being on its own separate retopo group), go to Voxel Room and hide all, but objectA volume.

Next, you enter PPP baking window and change the auto generated UV-set name from objectA_materialA to materialA.

6. Paint Room with completed bake of objectA:

-

Materials

:

-->objectA_materialA (even though it was changed to materialA) - contains objectA.

-

Objects

:

-->objectA - contains objectA.

Back to Retopo Room. Hide all groups but objectB, then go to Voxel Room and do the same with VoxTree layers. Then bake with materialA instead of objectB_materialA as UV-set name.

7. Paint Room with completed bakes of objectA and objectB:

-

Materials

:

-->objectA_materialA - contains objectA,

-->objectB_materialA - contains objectB.

-

Objects

:

-->objectA - contains objectA,

-->objectB - contains objectB.

Two materials, each holding only one object. Instead of one material (same UV-set name was used) holding two objects. Export model command will export two texture maps instead of one for both.

If you try to change the names of both materials in the Paint Room so they use the same name (materialA), the Export model command will produce one texture map for the last layer only (the first one gets overwritten by the second one because of them having identical names).

[ajz3d]

No response...

Guys, so there's no way of getting results from point #2 through baking?

[Tony Nemo]

Hang in there, ajz3d! Somebody is bound to cover this ground eventually (it beyond my beans & taters).

[ajz3d]

Yes, probably.

Alhough this discrepancy isn't something that completely blocks the workflow, it makes it way more difficult and time consuming to texture a model - the result of PPP Merge Op. of a model that contains multiple subobjects. Throwing every subobject into one basket means an increase in Hide tool usage and just imagine how fun and convenient it is...

I will report it to Mantis in hope Andrew will fix this in one of the nearest builds.

[ajz3d]

Reported as http://3d-coat.com:8081/mantis/view.php?id=1120

[ajz3d]

Any news about a fix for this issue?

[ajz3d]

Hello, it's me drilling the subject again. Today was doing some bake experiments and found something disturbing.

Use names correspondence for baking = OFF.

Voxel Room:

A mesh consisting of two objects: a bust and eyes.

Retopo Room:

UV Sets:

• uvset_A
• uvset_B
• uvset_C

Retopo Groups:

• retopoGroup_A
• retopoGroup_B
• retopoGroup_C
• retopoGroup_D

uvsetA contains:

• all faces from retopoGroup_A
• a single face from retopoGroup_B
• all faces from retopoGroup_D (separate voxel/surface object)

uvsetB contains:

• all, but one, faces from retopoGroup_B

uvsetC contains:

• all faces from retopoGroup_C

This results in:

Materials:

• retopoGroup_A_uvset_A: containing all faces of retopoGroup_A that were in the uvset_A.
• retopoGroup_B_uvset_B: all, but one, faces from retopoGroup_B.
• retopogroup_B_uvset_A: EMPTY(!?)
• retopogroup_C_uvset_C: all faces from uvset_C and retopoGroup_C
• retopogroup_D_uvset_A: EMPTY(!?)

No trace of that single face from retopoGroup_B as well as faces from retopoGroup_D.

Objects:

• retopoGroup_A_retopoGroup_B_retopoGroup_C_ - Everything's merged to one object; no trace of retopoGroup_D.

On export (Export Model), I got:

• (filename)_uvset_A_color.(fileExtension),
• (fileName)_uvset_A_nmap.(fileExtension),
• (fileName)_uvset_A_specular.(fileExtension).

Edited August 8, 2013 by ajz3d

[ajz3d]

I know that in the above example I've been doing some extraordinary (or maybe even really crazy) stuff with those retopo groups and UV sets. Normally I get results that I expect. This test was a surprise: lost faces, and textures only for a single material? Spooky stuff. I'm going to repeat it tomorrow from scratch, just to see if it wasn't a user error from my side.

Edited August 8, 2013 by ajz3d

[ajz3d]

This problem really starts to get on my nerves.

I've been doing some sculpting today on an imported object. The object has multiple sub-objects and two materials. Voxel Room has done pretty good job in separating objects into VoxTree layers and naming them properly.

I imported the retopo mesh to Retopo Room and that's when the things got nasty. Again, no UV sets were created for materials. Sub-objects were separated into two retopo layers which were named after materials. Now I have to manually separate all 25 sub-objects myself and move them to their own layers, plus - I need to recreate UV sets. So I'll be wasting about half an hour to fix it.

 

Why can it work fine in the UV Room but not in the Retopo Room???

Can't nothing be done with this???

[AbnRanger]

I'll just say this...long posts tend to get fewer responses, if any. Why? Cause most people are just stopping by...kind of like checking their e-mail. They typically don't have lot's of time to help solve other people's problems. Thus it has to be presented in a concise manner. Best way to do that is to screen record your question. It will help others better grasp what it is exactly you are asking or having trouble with.

 

This applies to e-mails to Andrew. Send him a lengthy one and you can count on not getting a response. He is so busy, he has to budget his time efficiently....long-winded e-mails likely won't get read.

Edited September 10, 2013 by AbnRanger

[ajz3d]

OK, I'll knock out a video to demonstrate the problem and will post it as soon as possible.

[ajz3d]

Done.

Sorry for my English.

[Malo]

The problem is the missing uv set that should be created automaticly, correct?

 

PS:

How did you select the complede uv from an object?

Edited December 20, 2013 by Malo

[ajz3d]

The problem is the missing uv set that should be created automaticly, correct?

Yes, but this isn't the only problem here. I'll try to summarise them:

1. UV sets are merged into one, called Default. So yes, 3D Coat looses all UV sets on import and throws them into one bucket.
2. Separate objects are merged into groups determined by materials. For example, the original scene has three objects and two materials (+ one tile). When I import the file I get two objects that are named after materials.
3. All objects are merged into one after Merge to PPP operation.
4. Finally, and also after Merge to PPP operation, there are too many entries populating the Materials list. For this particular scene there should be three entries there: plastic, metal and metal's tile. Compare the merge result to the Paint Room import from the first half of the video (1:49) to see the difference.

PS:

How did you select the complede uv from an object?

Double-clicking an object with Select tool active (in Faces mode) selects all of its components (including UVs).

Edited December 20, 2013 by ajz3d

[Malo]

Thanks.

 

Ok. I dont think it is a bug. I think it is not supportet.

Maybe a Manits Request?

[ajz3d]

Maybe a Manits Request?

http://3d-coat.com/mantis/view.php?id=1120

[Creator]

Hi
I found workaround for this problem.

1) Import Obj file for example to Paint room (File=>Import=>Model For Per Pixel Painting);
2) Go to Retopo Room and click "Use curent low-poly mesh" under Retopo tab i Menu Bar.

3) Switch to other room for the moment and go back to Retopo Room, to refresh UVs (it won't refresh from some reason).

Problem is that importing model to Paint room forces you to create new scene...   (If i'm wrong, please correct me)
So you need to merge your sculpt scene to scene with prepared model in retopo room.

[ajz3d]

Thank you for your input Creator. It's an interesting workaround.

However while it helps in restitution of UV-sets, the use current low-poly mesh command merges all objects and puts it under currently selected retopo group. Also, it doesn't solve the problem of baking, because if I were to bake my hi-poly mesh now (I'd need to import it first because it's like you said - importing for PPP creates a new scene), it will create another object and several more materials in the paint room.

There's a definite flaw in 3D Coat here.

[ajz3d]

Assignment of different materials for each object in the scene, so they import correctly, can easily be automated with scripting. That is, if a 3D package the scene is exported from supports it of course.

Restitution of UV-sets could theoretically be scripted inside 3D Coat. The script would need to look inside OBJ file and determine which objects (or object groups: "g") belong to which UV-sets. Tiles (vt > 1) would have to be moved to separate UV-sets. I yet have to give it a closer look and see if it's possible. Don't have time for it now though.

 

But what materials, objects and UV-sets are created in the paint room after baking is probably beyond all workarounds and can't be scripted. This requires a change in code.

[ajz3d]

Hurray, it's been fixed.

I think this thread may now be closed