Jump to content
3DCoat Forums

V4.5 BETA (experimental)


Recommended Posts

  • Advanced Member

This is more for the purpose of generating an AO map for PBR texturing on a SubD model straight out of Nvil.  I wanted to test PBR but didn't want to have to generate a low poly mesh and bake normal maps etc.    This would be the usual method when creating game ready assets.

 

I was using Calculate Occlusion with the Lights method.  I don't know any other AO calculation method that uses Lights.. what's that all about?

Link to comment
Share on other sites

This is more for the purpose of generating an AO map for PBR texturing on a SubD model straight out of Nvil.  I wanted to test PBR but didn't want to have to generate a low poly mesh and bake normal maps etc.    This would be the usual method when creating game ready assets.

 

I was using Calculate Occlusion with the Lights method.  I don't know any other AO calculation method that uses Lights.. what's that all about?

 

 

The light AO method comes from the olden days of 3D. It's a trick of sorts, and was pretty fast compared to "real" AO at the time, and was used a lot because of that. These days, there are a number of different methods of calculating AO. I'm sure there is a much faster way than using the ol' light trick. :)

  • Like 1
Link to comment
Share on other sites

  • Advanced Member

Yes, I agree.  I am baking my maps in other apps until there is a more desirable result for generating AO.  I remember this being an issue in 3DCoat, what? Maybe 4 years ago now.

Link to comment
Share on other sites

  • Advanced Member

I agree. I tested the AO calculation method using lights in exactly 2 cases, both of which produced unacceptable results in an even less acceptable time frame. Should be removed entirely from 3D Coat in favor of a more up-to-date algorithm.

Link to comment
Share on other sites

  • Advanced Member

Oh.  I didn't realise work on 3DCoat had slowed down that much.   I haven't frequented these boards for a long time (though we still use 3DC at our studio daily)  and from the outside it still seemed like the production pace was still frenetic.

 

I still love this program though, and we're quite close to adopting using it to paint PBR Materials.  It still needs a bit of refinement but enjoying how 'on target' painting is now.

Link to comment
Share on other sites

  • Contributor

Oh.  I didn't realise work on 3DCoat had slowed down that much.   I haven't frequented these boards for a long time (though we still use 3DC at our studio daily)  and from the outside it still seemed like the production pace was still frenetic.

 

I still love this program though, and we're quite close to adopting using it to paint PBR Materials.  It still needs a bit of refinement but enjoying how 'on target' painting is now.

Work on 3Dcoat has far from slowed down....development speed is still frenetic :)...its just that raytraced AO is  a feature Andrew does not seem to want to tackle (maybe its much more complicated to implement than we think) 

Link to comment
Share on other sites

  • Reputable Contributor

Work on 3Dcoat has far from slowed down....development speed is still frenetic :)...its just that raytraced AO is  a feature Andrew does not seem to want to tackle (maybe its much more complicated to implement than we think) 

That's pretty much what I took from Andrew's statements about both (AO and CUDA recompile)...he doesn't want to invest the amount of time in those, because he doesn't think the benefit will be enough to warrant it.

Link to comment
Share on other sites

  • Advanced Member

RE: pace of dev;  that's great to hear;  I miss the days of giving feedback to Andrew and for him to respond in person.  

 

I feel that super fast raytraced AO is a must if 3DCoat is to compete with the likes of Substance Painter/Designer (which does have very fast baking)  It is an integral part of PBR Materials, as is creating quality curvature maps.

Link to comment
Share on other sites

  • Contributor

Date Submitted - 2012-03-22 04:07

:(

 

Does Andrew drop by here any more?

he  comes here almost everyday and even sneek in updates some bug fixes solely reported on forum....

As I wrote AO is just something that seems to be in limbo.....TONS of other feature request have been added since 2012( almost an incalculable amount actually)...

Link to comment
Share on other sites

  • Advanced Member

..and he is but one man (even if that's a super man)  :)

 

I guess it must be hard to prioritise what is most important if there is a seemingly insurmountable mound of requests to get through.  Especially if Andrew also has to fire fight the bug list at the same time.

Link to comment
Share on other sites

Note:
 

Also, from a development standpoint - a huge application like 3D-Coat requires a very large team (now 13 in number*) to properly maintain and advance this professional application.

 

* italic is mine

Link to comment
Share on other sites

Haven't notice a Photoshop like masking feature there. Currently it's not black for invisible parts and white for visible ones, also mask needs to be a separate layer.

 

 

There is one somewhere on there. It was already voted on and is being developed. :)

 

As for it being a separate layer, you can already do that with a clip mask. We now need layer masks (similar to PS).

Link to comment
Share on other sites

  • Advanced Member

3DC crashes when I try to bring any model for UV mapping from 3ds max to 3DC using AppLink and there is already another model in UV room. Program asks if I want to start a new scene, I agree and then 3DC crashes. Can someone check this, please?

Edited by Vipera
Link to comment
Share on other sites

  • Contributor

Maybe it's time to change the AO calculation algorithm to something more conventional and reliable?

20 minutes of waiting (164 lights, 12 smoothing steps) and the result...?

attachicon.gif3dcoat_ambient_occlusion.jpg

<_<

Same objects, but AO baked in Houdini (two 2048x2048px maps, 256 samples each). The bake took approximately 1 minute 37 seconds per each map (or even less, for the second map) . This shows a huge gap between 3D-Coat's AO calculation method and the methods used in other software. I hope this will be a kind of a stimulus, or a call for action for improving (replacing) the outdated AO algorithm that 3D-Coat uses.

 

post-12523-0-62521500-1427927743_thumb.j

post-12523-0-23744800-1427927819_thumb.j

 

Before V4.5 I wasn't interested in calculating occlusion in 3D-Coat, but now, when most of the PBR materials utilize it, the quality and calculation speed of AO became very important. Using the lights-based trick is no longer an option. Not only because it takes ages to calculate (see below for this), but also because the results are, and believe me I'm really sorry to say this, terrible.

One last thing.

3D-Coat performs occlusion calculation for all objects and materials in the scene. It ignores hidden and locked flags on objects/materials. The thing is, that sometimes (for many reasons) I want to bake occlusion only for certain objects or materials, and not for everything at once. Baking AO for all objects greatly increases render time, because there's much more unnecessary calculations that 3D-Coat needs to perform. It's also additional work for me, because I need to remove parts of occlusion layer of one object that affects the others. Please do make the Calculate Occlusion command respect hidden and locked objects/materials.

 

PS. Hidden and locked state is ignored by many functions of 3D-Coat.

Edited by ajz3d
  • Like 1
Link to comment
Share on other sites

  • Advanced Member

I have lost few hours of my work making UV mapping on objects imported from 3ds max and exported back to max after UV mapping. I forgot to press damn button "Apply UV-set" before each export... :-( Don't you think that Apply UV-set has to be pressed automated before export? That was a silly waste of time.

Link to comment
Share on other sites

  • Contributor

An observation:

I've noticed that deleting paint layers of high polycount, UV-ed models takes a considerable amount of time. For eight 2048px2 UDIM tiles and a model consisting of 3.7 million quads, it takes about 4 minutes and 10 seconds to delete a single layer on a 3.5GHz CPU.

It gets much better on a 900k model (lower subdivision by one level) with the same UDIM configuration, where it takes 14 seconds. That's four times less polygons, but it's almost 18 times faster.

Edited by ajz3d
Link to comment
Share on other sites

  • Reputable Contributor

I tested your file... I had no problems in the same area. In other test, I also just painted depth / color over your bad areas and they disappeared...

Linux 64 bit non-cuda  (GL64) with a brand new install of 4.5.Beta15.

 

The above does not mean there is not a problem but in Linux it does not appear to happen. Maybe some form of graphical glitch but am only guessing.

Second picture is where I painted depth / color over your problem area.

post-518-0-57355900-1427990082_thumb.png

post-518-0-04384900-1427990403_thumb.png

Edited by digman
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...