terrain editting and texturing

[mpmumau]

im wondering how you guys do terrains with RF? i can create the geometry in nems mega 3d terrain generator, and even texture it in there. however i dont know how to bring the texture from nems into a level to apply to geometry. also, the texture editing in nems doesn't blend textures where they meet (i.e. when a sandy texture meets a grassy texture, its appears in blocks.) im used to using the unreal editor uedit. that program uses layers that blend the textures together where they meet. is there any program that can make terrain like that for RF?

[federico]

if you put the same texture (with the same name) in the txl texture pack, then, when you import the map file, the terrain is textured correctly. Multi-layering on texturing isn't possible nor shader effect to blend the textures. You can use transition textures to have that effect (http://www.garagegames.com/mg/snapshot/view.php?qid=490)
or generate a unique large texture for all the terrain, then broke it in several pieces and then apply on NEMS like a mosaic (that's what I'm trying to do now ).

[mpmumau]

aha thats what i was guessing about the texture blending. do you mean the RF txl pack must have the same textures with the same name as the textures you use in nems? if so, i guess ill have to finally figure out how to make txl packs, hehe. if you have a screen of the mosaic method, id love to see. im trying to take a project i started in unreal and bring it into RF if possible. i'd ultimately like it to be a "massive single player" game where this is just one very large outdoor level, with as little distance fog and distance clipping as the engine can afford. i'm still working out the basics of how to use this new engine however. the mosaic method would likely be the most attrative, although i guess ill just have to experiment. thanks!

[mpmumau]

actually i was thinking about that mosaic method -- creating one large texture and dividing into smaller squares. doesnt that put a heavy burden on the engine to have so many textures? if i made a very large terrain with a larger number of textures (albeit with distance fog and clipping) to account for each "square" of the terrain, is that going to slow things down a lot?

[federico]

I really don't know, I was thinking about this mosaic possibility but create a huge level with this method may put you in some troubles. In my opinion it's better to usemore little textures than to have a big one. Anyway the better way is to use transition textures, and that's the way I'm using. I've started with the mosaic idea but I found the right transition between the textures (using the texture archive I posted before). Another way is to use a static mesh using collision detection = 4, in this way your terrain is an actor (you can use milshape to create it), and you can easily make it as a mosaic breaking it in several pieces. You will still have the problem to blend the texture but you probably can handle it in a better way. See the examples in the hike1 site to figure out what's the better way for you.

[hike1]

http://terrymorgan.net/download.htm


I've decided that static mesh terrain is too buggy and too
texture bloated, so I went back to making brush terrain only texture tiles with
texturemaker. Ultima 9 used about 60-80 of these 128x128's to cover their whole
giant world. Mine are going to
be uglier of course. 1 thing, if
you're using Nem 256x256 triangles, use 256x256 tiles,
and there's a lot of flipping and rotating involved.

Don't bother texturing anything in Nem's, it won't transfer to Reality factory.

http://terrymorgan.net/terraintiles.jpg

The 1024x1024 was also made in texturemaker, but it looks too repetitive.

[federico]

Don't bother texturing anything in Nem's, it won't transfer to Reality factory.

Really I got it working. I simply put the bmp files in a folder then I add it to the nems packages using 'add folder' (not 'add package' I don't add it as wad package) then I export the terrain as map using no export options at all (no Hints, no Sky...). I add the textures to the txl pack, then import the map correcly textured.

a tip: if you make your terrain a 'model' then re-building trees is quicker. If you even group the terrain, you can make it invisible unchecking the 'visible' button and then choosing to see only the visible groups. In this way the terrain doesn't affect the re-building trees. This makes things easier with a huge terrain (or everytimes you move a brush, it rebuilds... rebuilds... rebuilds... ) .

[Tabulanis]

I have to say for really pro looking terrain you have to use static geometry.
If you just want a hill or hilly type terrain then you can go with the other. If you start with a complete model, (Terrain.rocks.cliffs etc) then break it up. Then export the mesh but DONT move the pivot axis. you will have all the parts line up perfectly in the editor. make it an SEP not SME. Do not use colision. Then build a base colision model with as few faces as possible. Make your textures (in my opinion) each seperate and then paint shadow and lighting. If you use photoshop or a ray tracer the shadows can be quite dramatic. Then import them and set their ambiant to full.

The reason I say its good to do all this is if you think about it games like quke4 doom3 FEAR etc, have really slow frame rates do to all the detail and post proccesing. RF dose'nt do any of that but it can cruch those numbers. So if you cant get great lighting from the editor use 6-20 times the textures. Detail goes up to starteling levels and it still reders at a decent rate in comparison to a modern game. Stay away from SME collision though I tried that road... very frustrating. it takes a long time but its worth it.

[mpmumau]

i think im starting to understand that using static meshes is the best solution for terrains. however, tabulanis, there are a few terms and things you talk about in your post that i just dont know what they are. what do the acronyms "SEP" and "SME" stand for? from what i could gather you were referring to a type of collision detection you could use for a static mesh of a terrain, but i wasn't sure.

also when you say

Make your textures (in my opinion) each seperate and then paint shadow and lighting.

you do mean make a seperate texture for each section of the static mesh, which is divided from the larger, total static mesh right? in that case, it would probably be benefitial to originally make a single, gigantic texture and break it into sizes fit to the broken-down static mesh pieces, right?

i was also confused about what you meant by saying

So if you cant get great lighting from the editor use 6-20 times the textures.

as i understand that what you're generally talking about in that part of the post is "baking" the effects of lighting onto a model in a 3d model editor of choice, but im not certain how you could use more than one texture for a given mesh? do you mean the "layered" textures like bumpmaps, specularity maps, etc?

finally, i also don't know what SME collision is. from your post, i hope im not inadvertantly using it, hehe.

i'm new to making games, and although i can model and map with some skill, i'm still learning the ropes. even though i vaguely understand what some of these terms mean, it helps hearing them re-explained by others, especially in terms of practical uses like you've started to do, and i thank you.

on an unrelated note -- i still haven't figured out how to bake lighting onto a texture in maya, anyhow. i have a tutorial for how to do it in max, but as the interface of max has felt more awkward than the maya interface for me personally, im really not proficient in it. does anyone know how to bake textures in maya? id really appreciate advice.

[hike1]

Don't bother texturing anything in Nem's, it won't transfer to Reality factory.

Single textures will, but a terrain tile set will be fubared as it
needs to be rotated and flipped around a lot.

I'm waiting for tabulanis' demo of static mesh terrain, it looks
great but RF was never made to do static mesh terrain, and
doing it in the editor is a nightmare. Why I'm checking out Ogre, it has none of those problems.

Federico, World Editor 2 doesn't have the 'rebuild every time'
bug of World Editor pro.

Oh, the terraintiles.jpg was moved to
http://hosted.filefront.com/hike1

[mpmumau]

does ogre have a shell like this (i know RF is a shell for the genesis engine.) im not really certain im sold on this engine/shell, but from what i can tell the scripting is vastly easier to understand than the scripting was for the unreal engine. plus, i like the idea of using something open source and stand-alone rather than modding a game, and requiring the user to own it.

[Tabulanis]

Terms

SEP = static enitity proxy

SEM = Static mesh entity

As afr as one big texture and baking

Yeah I start with one biggie witch I build using layered textures. You can "Fake bake" by rendering from the top view of your mesh with no perspective. same with sides for cliffs etc.

somwtimes this works really well but photoshop editing usualy comes into play for really nice looks.

[hike1]

does ogre have a shell like this (i know RF is a shell for the genesis engine.) im not really certain im sold on this engine/shell,

This is the only one that resembles RF, it's open source, but you need to learn Blender to get models in. Other bad parts are there's no
way to lock up your models, textures, being
open source, there's only 1 guy doing it, and
I still don't know how to get any buildings, etc. into his game.

Upside is it's a free modern engine, somewhere down the road someone will use
Ogre for an RF type game development, so
it's probably not a waste of time to learn how
to make stuff for it.

http://forums.dfworkshop.net/viewtopic.php?t=367

[AndyCR]

does ogre have a shell like this (i know RF is a shell for the genesis engine.) im not really certain im sold on this engine/shell, but from what i can tell the scripting is vastly easier to understand than the scripting was for the unreal engine. plus, i like the idea of using something open source and stand-alone rather than modding a game, and requiring the user to own it.

i'm working on a version of rf that runs on irrlicht.

[mpmumau]

eh RF based off of the genesis engine really isn't that bad, and being so new to this stuff (i only even started trying to make/mod games last september) i really shouldnt be picky. i know that the problem is more my lack of knowledge about how to make games than the engine i attempt to make it on, hehe.

i ended up reading tabulinis' other posts after he replied to this one, and i realized he's written quite a bit on this exact topic before. i wish i could just watch over his shoulder, especially to learn more about baking the lighting onto textures, but i think ill manage. im realizing now, however, that since ive decided to make a single massive level for my game that what i really need to do is get to work on planning the level out with greater detail, especially if im going to use this engine, because designing on the fly isn't going to cut it for a variety of reasons.

that said, if anyone is interested in giving me a hand, hehe, let me know.