ATLAS TEXTURE, whyyyy? !!!

Started by Santiago, May 16, 2020, 17:23:08

Previous topic - Next topic

Santiago

ATLAS TEXTURE, whyyyy? !!!
--------------------------------

I noticed that they use texture atlas, I had never used it, and it seemed like a tedious manual process, which in simple geometries may be acceptable, but in complex models with many elements and objects it can be an unfriendly process.

I think that the solution to the atlas texture is to generate a function that automatically generates this process, both to generate the bitmap with the colors as well as the automatic mapping of the vertices.

Does anyone know what is the logical and technical reason for this to exist?
I see people do the process of converting their materials to single textured atlas material manually .. whyyyy ????

why manually ???? whyyyyyyyy


I am thinking of making a function, to adapt to these new modern concepts.

but I think, all these years, I worked my 3D models in 3dsmax, I used max or B3dpipeline materials inside max, and I exported in .3ds, .x or .b3d and Blitz3D I opened my models, with colors, with brightness, with alpha, with textures, with blends and their childs.

reason why Blitz3D really was always very friendly in this matter, I solve my life, modernity is not so friendly with what blitz3d always was.

3DzForMe

Quotereason why Blitz3D really was always very friendly in this matter, I solve my life, modernity is not so friendly with what blitz3d always was.

Yep, Blitz3D is the daddy ;)
BLitz3D, IDEal, AGK Studio, BMax, Java Code, Cerberus
Recent Hardware: Dell Laptop
Oldest Hardware: Commodore Amiga 1200 with 1084S Monitor & Blitz Basic 2.1

Kryzon

Quote from: Santiago on May 16, 2020, 17:23:08
Does anyone know what is the logical and technical reason for this to exist?
I see people do the process of converting their materials to single textured atlas material manually .. whyyyy ??? ?
This existed since the Blitz3D times (Direct3D 7), which is the "single surface" technique aka batching: reducing API draw calls and reducing texture switching. More info here: https://thegamedev.guru/unity-performance/draw-call-optimization/#tab-con-18

Such an optimization had huge benefits in Blitz3D, like when using hundreds of particles. The term "single-surface particles" came up a lot in the blitz forums.

Making an atlas by hand seems tedious and open to human errors, it's better to invest in either buying a tool for this, or making one yourself. There used to be a script for 3ds max that did this: http://www.scriptspot.com/3ds-max/scripts/texture-atlas-generator

The manual way of doing this without a specialized tool is by texture-baking. In Blender you can do this by joining meshes together into a single object (logically joining them, not physically, as they're still separate objects), packing their UV islands and then baking this single object to a single texture that becomes your atlas. There's also a bundled free add-on for that: https://archive.blender.org/wiki/index.php/Extensions:2.6/Py/Scripts/UV/TextureAtlas/

Derron

@ Kryzon
with Blender 2.80 and newer you have "multi editing" - so select all the desired objects, press "tab" and you could edit all of them simultaneously. So how does this help? You can now also bake multiple objects to the same texture more easy.
Of course you can still use TexTools or other addons which allow easier baking of all this normal, cavity ,...
for 2.8 you could use this port: https://github.com/SavMartin/TexTools-Blender


bye
Ron

Kryzon

@ Derron thanks for the suggestion, as long as you can create a new UV channel for all objects and repack their islands to be used on the atlas texture, then whatever you can use to speed up this process is helpful. 
I'm deliberately using 2.79.7 (the last nightly build of the 2.7x series) because it's got all the features I need and is really really fast especially on low to mid-range systems.

I don't really like 2.8x, I'm not fond of the idea of making the upgraded version have bigger CPU and GPU requirements than the previous. To me an upgrade should make things lighter, not heavier (the program itself can have a larger HDD footprint from the bigger executable and supporting files, but in terms of performance it needs to be better). The viewport performance suffered a lot after it was switched to fully programmable, even the matcap / workbench viewport modes are slow, whereas 2.79 still uses fixed-function rendering as I understand it, I even use immediate-mode OpenGL to draw on it in my add-ons (where I support 2.7x and 2.8x with the same dedication).

Derron

Yes 2.80+ do no longer run on my HP Elitebook - on Windows (OpenGL 3.0 there). Should run on Linux (3.1 supported there).


bye
Ron