Universal Forum Archive

Hia,

One of the bigger (but not that big) changes for the 0.52.0 client will be added support in the graphics engine and .atm format for models with multiple materials.
What this means is that you'll more easily be able to create single models with shiny glass windows and stuff like that.

I will now commence with a random braindump of what else the material system means (Much of this may not make much sense initially :] ) :

It means you'll be able to use models that have more than one texture. You can now load a .x file that references multiple textures and it'll display and save properly as a .atm.

The extension to the .atm format means that when you have a material with multiple materials, the .atm file will include the texture data. This means .atm files get bigger, but you have a single file with all the graphics data needed for the model.

This leads to new possibilities for the way models are built. One (or more) of the textures can be overridden by the world owner, so you could (or probably should), for instance, build shop models where all the walls, windows and stuff are done using normal materials, then thered be a signpost which can be overidden by the worldowner.
Thereby, a worldowner might use the same "shop" model for various buildings on his world, but override each one with a simple signpost graphic indicating the type of shop.
like we do now, but easier. bonus.

Ultimately materials could also mean much nicer spaceship models, planets, buildings, vehicles and characters. In particular i reckon (if someone puts in the work with the new converter) existing planets and spaceships could be made a whole load prettier.

The extensions to the atm format mean that soon we could also support normal maps, environment maps etc that'll potentially make lots of things look very um, this-gen, rather than last-, but not quite next-. That may come soon or may take another year :].

Note : The bad side : Models with multiple materials will not render as quickly as those with just one, so expect a fps hit if you use a lot of them. (Particularly for those people with not so great PCs)

Finally, in addition to all that, theres been a proverbial pant-load of work done on the model converter, which as well as a material browser, now includes face-picking tools (so you can select a bunch of triangles and assign them to a new material) and a basic UV map editor. (This latter, barely functional, tool will at least enable the budding artists amongst us to fairly easily take existing models and remap them to multiple textures and materials and allow lots of windows and shiny effects. Oh yes.)

I will now stop writing, and at somepoint in the next few days upload all this stuff that will probably all fail miserably to work right.

all this newness to anticipate, waiting aches me more now XD

Mit wrote:...that'll potentially make lots of things look very um, this-gen, rather than last-, but not quite next-.

Made me laugh.

------

Can't wait to be able to use the multi-materials. That will make it so much easier to use free web models in-game.

I don't suppose you've looked seriously into revamping the power of the 3D engine so that we might be able to up the poly counts to new heights? Or better yet, use bump maps.

*drools*

http://developer.nvidia.com/object/physx.html XD

been seeing this in the cvs for a while. glad to see an official post about it

so...if you have one of these atm models with the multi texture data file, how will a world owner assign this texture to there world?
just assign the data file as the texture?
just have the model in the names file and no entry for a texture?
assign a blue #255 transparent texture to prevent a texture override or grey missing texture override?

mit wrote:What this means is that you'll more easily be able to create single models with shiny glass windows and stuff like that

I found all this much easier to understand once I realised it's not really multiple materials in the same sense another game might use them. It's really multiple textures, and each texture can have different lighting properties.

I emailed a handful of you with the beta model converter and some rambling notes about this... in essence, though, it means to take proper advantage of it you need to think about modelling slightly differently - any part of a model that will end up having its own texture will need to have its own polys. For example, a spaceship panel with a glowing light on the side - the light needs to have its own polys in the mesh.

This is the same as any other game where you'd need separate polys if you wanted different bits of a model to use different textures. Where it's different is that normally you wouldn't need to do that for something like a glowing light on a panel - you wouldn't normally need to model the light, you'd just use a diffuse and lightmap and it'd look the same. Our way just means a higher polycount and more forethought to your modelling.

I'm sure mit will have somethin to say about it but equally i'm sure this is all true... Hopefully when we get to the stage of having environment maps and so on, we'll just be able to combine materials in the proper sense, at which point yes I'll start going back thru the existing space models mit :]

In the meantime, as mit says, the funky new stuff on the model converter lets us all play with this and revamp existing models to a certain extent - but as many of them have been built with efficiency in mind, separate polys for things like windows and shiny bits probably aren't there... there will be limits to what can be done without remodelling. I know cos i've tried it :]

zaroba wrote:so...if you have one of these atm models with the multi texture data file, how will a world owner assign this texture to there world?
just assign the data file as the texture?
just have the model in the names file and no entry for a texture?
assign a blue #255 transparent texture to prevent a texture override or grey missing texture override?

I believe the atm file references the texture, so you'd just reference the model. Equally the atm file references the override texture (or the lack of one) so it's all handled in the model. They're more like package files than model files now.

One thing I don't understand, though, is how they handle situations where multiple models use the same materials - say (for example) you have several variants of a tree, each using the same wood and leaf textures. Seems daft to store a copy of the texture in each atm.

Or, using mit's example - say you have several different shop models for variety, each using the same basic shop texture but with different override textures for signs. Again, is daft to store a copy in the atm file...

f

So, when (slash maybe where?) can we download this fantastic new model converter?

i was just wondering the same thing

its not available on the site yet.

Waiting for a few changes to be made - it's still in beta. Couple of notes on my previous comments in the meantime...

Fooli wrote: I believe the atm file references the texture, so you'd just reference the model. Equally the atm file references the override texture (or the lack of one) so it's all handled in the model. They're more like package files than model files now.

This is half right I think. The atm doesn't reference the texture, it includes it - if you have a model with multiple textures. I think the implication is that old-style atms (with just one texture) will get the right texture assigned the same way they do now, via the world server; new-style atms will include the texture in the atm file itself, so in the world server you'd just assign the atm file.

That just leaves the override texture - I've no idea how that'll work, but I'd guess... if you have a multi-material atm and then you assign a texture to it, it'll use that as the override texture. This should all make more sense when you have the MC to play with .

Fooli wrote:One thing I don't understand, though, is how they handle situations where multiple models use the same materials - say (for example) you have several variants of a tree, each using the same wood and leaf textures. Seems daft to store a copy of the texture in each atm.

While it may (arguably) be daft, this is the way it is for now. An atm file will include the textures it needs for the model. Multiple variants of a model (for example, a tree sharing the same textures) would indeed duplicate those textures However texture files are compressed in the atm format. To give an example, I'm testing/working on a model with ~9,000 polys and 10 textures, each a 1024x1024 bitmap, and the whole atm including textures is only 450k or so. So duplication isn't necessarily too painful, and generally different models will have different texture files anyway.

f

the same issue would happen if you had a model that had multiple texture designs (like so many current models do).


could just have models with known multiple texture variants or multiple models that share a single texture continue to use the old system of having a one piece texture file and old style model/texture assigning.

although it wouldn't be the 'new' way, it might be the better way.

any updates on the MC?