Coming not very soon, to a world near you... an awful lot still to do.
f
sp33d
-
morbydvisns
- Posts: 1889
- Joined: Sun Jan 30, 2005 12:51 am
its not an in-game shot :p
but, i imagine walls like that would be a pain to make due to the 5 tile collision radius resulting in each section being limited to filling in a 10x10 tile area and likely not being able to be replicated on the track. unless 1 small piece is used and rotated, but it'd leave jagged turns.
landscape mesh might be the best way. don't know how you'd do the collisions then.
speaking of landscape meshes, i've been pondering a few world designs that used mostly landscape meshes instead of regular building models to simulate things.
but, i imagine walls like that would be a pain to make due to the 5 tile collision radius resulting in each section being limited to filling in a 10x10 tile area and likely not being able to be replicated on the track. unless 1 small piece is used and rotated, but it'd leave jagged turns.
landscape mesh might be the best way. don't know how you'd do the collisions then.
speaking of landscape meshes, i've been pondering a few world designs that used mostly landscape meshes instead of regular building models to simulate things.
it's not an in-game shot, no... but yes, it's a mesh landscape that'll just slot into the game. Eventually. Somehow :] (actually all landscapes are meshes but this one starts life in a modelling prog, rather than a heightmap).
The tricky bit, apart from the actual modelling, is working out how to export the various bits and pieces and recombine them in-game, something I'll need to work out with mit at some point. The MC has a maximum polycount it'll load, and i'm already way over that. So I'm prolly going to have to export the land bits as one mesh, the buildings as another, the trees as another, and so on... and hope mit can find a sensible way to recombine it all :)
The point of the render, btw, is that once i've got some decent textures i plan to bake the lighting into them. Ie, make it look pweety. It won't look as sharp in game but we'll have something approaching this sorta look, with nice shadows and so on.
Collisions and so on will be handled by, er, mit :)
Entirely model-based landscapes are already possible in the current client using a bit of a hack/workaround (which, in fact, I've forgotten how to do). Mit just needs to finalise the code and release it, IIRC. Which he'll do, mostly likely, whenever I get this feckin track finished. It takes aaaaages.
If you're interested in building landscapes this way it's certainly worth starting some ideas now. It's tricky but a fun thing to do (caves! put objects anywhere! etc). Obviously to get game stuff like building access going you'll need to use some of the traditional world-building methods too.. also something I'm not quite sure how we'll handle, but that's just more code stuff mit needs to do.
It all ties into the new multi-material capability of the atm format, so you need to start thinking about modelling with materials in mind. For example, I can export my landscape, track and walls as one model. The land uses one material (texture); the track another; the walls yet another. If I want to have a section of wall look different, I just give that section another material ID and change the texture in the MC. If I want the track to have different lighting properties, I edit its material properties in the MC (maybe it's a bit shinier than grass). That kinda thing.
With different textures for different bits of the model you don't have to cram it all onto one UVmap, so the overall quality is higher. In fact, you don't have to map it in the normal way if you don't want to: everything needs UV coordinates, sure, but you can simply box map most stuff and have it share textures.
For example, I have two types of grandstand at the moment. Different models, but both have a roof, fence, seats, floor ect - and all those bits share the same roof/fence/seat/floor textures. The textures themselves are just blocks of colour (one big roofy looking thing; one big plasticy seat sort of texture... and so on). The UV coordinates for different bits of the roof/seats etc all overlap but it doesn't matter, as long as there is no seaming/stretching.
It's much quicker that way. The main issue is if you want to bake lighting into the textures, which I do... in that case everything needs its own textures and will need mapping in the traditional way. A task I'm not looking forward to :]
If you aren't using a modelling prog that supports material channels/material IDs, it's probably time to switch to one that does.
f
The tricky bit, apart from the actual modelling, is working out how to export the various bits and pieces and recombine them in-game, something I'll need to work out with mit at some point. The MC has a maximum polycount it'll load, and i'm already way over that. So I'm prolly going to have to export the land bits as one mesh, the buildings as another, the trees as another, and so on... and hope mit can find a sensible way to recombine it all :)
The point of the render, btw, is that once i've got some decent textures i plan to bake the lighting into them. Ie, make it look pweety. It won't look as sharp in game but we'll have something approaching this sorta look, with nice shadows and so on.
Collisions and so on will be handled by, er, mit :)
Entirely model-based landscapes are already possible in the current client using a bit of a hack/workaround (which, in fact, I've forgotten how to do). Mit just needs to finalise the code and release it, IIRC. Which he'll do, mostly likely, whenever I get this feckin track finished. It takes aaaaages.
If you're interested in building landscapes this way it's certainly worth starting some ideas now. It's tricky but a fun thing to do (caves! put objects anywhere! etc). Obviously to get game stuff like building access going you'll need to use some of the traditional world-building methods too.. also something I'm not quite sure how we'll handle, but that's just more code stuff mit needs to do.
It all ties into the new multi-material capability of the atm format, so you need to start thinking about modelling with materials in mind. For example, I can export my landscape, track and walls as one model. The land uses one material (texture); the track another; the walls yet another. If I want to have a section of wall look different, I just give that section another material ID and change the texture in the MC. If I want the track to have different lighting properties, I edit its material properties in the MC (maybe it's a bit shinier than grass). That kinda thing.
With different textures for different bits of the model you don't have to cram it all onto one UVmap, so the overall quality is higher. In fact, you don't have to map it in the normal way if you don't want to: everything needs UV coordinates, sure, but you can simply box map most stuff and have it share textures.
For example, I have two types of grandstand at the moment. Different models, but both have a roof, fence, seats, floor ect - and all those bits share the same roof/fence/seat/floor textures. The textures themselves are just blocks of colour (one big roofy looking thing; one big plasticy seat sort of texture... and so on). The UV coordinates for different bits of the roof/seats etc all overlap but it doesn't matter, as long as there is no seaming/stretching.
It's much quicker that way. The main issue is if you want to bake lighting into the textures, which I do... in that case everything needs its own textures and will need mapping in the traditional way. A task I'm not looking forward to :]
If you aren't using a modelling prog that supports material channels/material IDs, it's probably time to switch to one that does.
f
-
morbydvisns
- Posts: 1889
- Joined: Sun Jan 30, 2005 12:51 am