Why should we use Handplane ?

Cathodeus

Hello,

I have a bit of time. i'll be deeping handplane topic.

But before spending my time on it. I would like to know why should we use Handplane ?

Here is my opinion, can someone confirm or deny those points :

1. It can reduce the number of vertices per object [less smoothing group, less poly compensation].
2. It enable artist to stitch their uvs [less uvs cluster so less waste of pixels].
3. Better shading and normal map behaviour.

What do you think guys ? Am i right ? Adding a software to a pipeline is still really sensitive so we need more infos.

Thanks.
Max.

imperator_dk

- Retain high quality texture source files in engine agnostic format.

Cathodeus

To me this is the less valuable point. Not enough, to afford teams working with it, spending money on licenses, etc ...

1.Our engine is not supported by Handplane --> Frostbite
2.Our current game are shipped without it and look already good.

But if the it allow us to make more optimised assets : with less vertices, less uvs clusters, less pixels losts than i'm intrested.

imperator_dk

Cathodeus wrote: »

1.Our engine is not supported by Handplane --> Frostbite

The whole point of handplane is to provide Tangent Space corrected normal maps to the target engine's renderer, if you're not making assets for any of the engines handplane supports then there is absolutely no use for handplane at all.

Cathodeus

So as i'm new to EA i don't know if the engine is already synced.

So i'll be reformulating my question :

Do having a sync tangent space normal map output from maya to the engine.

1. Can reduce the number of vertices per object [less smoothing group, less poly compensation].
2. Enable artist to stitch their uvs [less uvs cluster so less waste of pixels].
3. Better shading and normal map behaviour.

Massimo.

If frostbite is not synced with maya than i'll be proving it later.

imperator_dk

Having a synced tangent space means less hacking on the mesh to make normal maps look good and seamless resulting in less vertices as you need fewer smoothing splits and smoothing control loops.

Noors

That's a little weird question.

Synchronizing makes the normal map look right. Generation and display uses the same algorithm.

With unsynced workflow, you have to break everything to get the less compensation possible, so the errors are less noticeable.

With synced workflow, it will look good whenever you smooth everything or break it all. However, it's not really great to have huge compensation gradient everywhere as 8bit format and compression will damage this a bit. Also it probably makes editing harder.

So i wouldn't say you could reduce greatly the number of shells, but yes, correct shading for sure.
Now i don't think it would be of a great impact on pipeline. You could batch everything at the end.

imperator_dk

Noors wrote: »

That's a little weird formulation.

Synchronizing makes the normal map look right. Generation and display uses the same algorithm.

With unsynced workflow, you have to break everything to get the less compensation possible, so the errors are less noticeable.

With synced workflow, it will look good whenever you smooth everything or break it all. However, it's not really great to have huge compensation gradient everywhere as 8bit format and compression will damage this a bit. Also it probably makes editing harder.

So i wouldn't say you could reduce greatly the number of shells, but yes, correct shading for sure.

Depends on the compression format of the normal map for sure, however if you are using DXN (BC5) with a 16 bit aware compressor and 16 bit normalmap source files then there is next to no gradients that will cause a visible compression artifact.

AlecMoody

We are planing an SDK that will allow for implementation of custom tangent spaces. We are also very interested in adding support for more engines and frostbite would be something we would love to get working.

Also, there is another major use case. Let's say your engine already looks good but not perfect with an existing tangent space. For this example, an engine that looks 80% correct with 3dsmax tangent space. Traditionally, this would involve using splits and supporting geometry, test baking, making changes to fix errors, and then running bakes again. With handplane you can iterate much faster. The workflow would look like:

*Build your mesh to be efficient
*Iterate on your mesh only for projection quality
*Once your projection is totally clean create a tangent space map
*add supporting geometry only in places needed to clean up model
*make new tangent space map without rebaking

Handplane will spit out a tangent space map almost instantly so this is much much faster than running repeated bakes and you end up only adding supporting loops where it is absolutely needed. Also, I know that occasionally I will think I have everything on the model cleaned up and I will move onto to baking ao and texturing only to later find out I missed an error. In those cases, you will likely need a new cage for the new geometry and as a result you will need to re-run your ao bake which is extremely slow. Even worse is if you have already done your textures- in which case you are essentially locked into doing some hacky photoshop fix in those areas or trying to hide it with texture info.


also, to address what Noors said. Certainly fewer gradients will minimize issues related to compression. However, if you have worked on hard surface assets in a production environment with unsyced normal maps you will appreciate how much time and geometry are wasted on cleaning up shading behavior.

cptSwing

Also, "free" cleanup of projection errors.

chris89

Since you'll have some control over your engine's development (being inside EA?) you'll be able to get it matched up with your baking software and can avoid handplane alltogether.

imperator_dk

chris89 wrote: »

Since you'll have some control over your engine's development (being inside EA?) you'll be able to get it matched up with your baking software and can avoid handplane alltogether.

I'm pretty surprised that there isn't an internal xNormal TS plugin for frostbite.

AlecMoody

What should be more surprising to people is that artists have been complaining about tangent space issues for about ten years and very few developers have addressed it. It shouldn't take a third party like us to get things synced up but that's what it has come to.

haiddasalami

imperator_dk wrote: »

I'm pretty surprised that there isn't an internal xNormal TS plugin for frostbite.

Well if they're using Maya maybe their engine is synced to Maya tangent basis?

Cathodeus

Actually encquiring guys.

ZacD

Maybe handplane should come with a test assest with different normal maps included so people can test what tangent works best with a target engine if it's not one of the featured ones.

ENODMI

Th ability to see in Maya or Max whether your bakes are having issues because of unsync'ed tangent space or shitty geo is a pretty big deal to me. I used to fuss over my bakes endlessly... then handplane comes along and shows me that it's just the map itself in most cases. Having a clean worldspace map handy during texturing is also sweet bonus. Also, most editing is done within maya or max before you kick it out to the engine, so why not have an accurate representation of you model during this time. If you hand it off to someone else, and they use max instead of maya, just a quick run through handplane can make it easier on their eyes.

AlecMoody

Cathodeus:
Your original 3 points are valid for a well set up workflow from baking to engine. There are also lots of production time savings, which I personally think is the most important benefit.