Reality Factory

Most of my threads in this corner of the board are about outdoor enviroments. Again, I can't get the picture right because there are so many ways to approach and accomplish the same effects in Reality Factory. My problem really is discovering the engine limitations. Don't like to build something that is essentially doomed from the start.

Let's say I want to make a large outdoor map with a small (piece of) forest, a castle and a village. Now I will only do the basic landscaping with brushes and fill the rest in with models. The structures don't need to be accessible, at least not at the actual location in the map. Imagine a very simple battlefield like map.

Now if I recall right, one cannot make a single brushed 'room' or area larger than 4000 texels, right? Imagine I make series of smaller totally secluded areas that are all connected to eachoter by corridors like cave tunnels, narrow paths in the forrest. (Visibility will be totally blocked) Wouldn't that allow me to make a much larger map? Note, each area will be reasonably big.

Right, We've discussed this before that scaling is also an option to make bigger maps. But is scaling not just relative? I mean, if one would literaly scale a big game down, including the application of light- and visability calculations scaled accordantly, wouldn't it be exactly the same as the big version regarding the compile times and engine rendering for the game?

Also, every model, function door, etc. will be listed as an entity, right? In a previous thread of mine Jay was so kind to inform me that the entity limit is about 250, quite low if one is to simulate a forest or a city where trees and buildings are all models.

What I'm trying to figure out is the best way to approach a game with large outdoors and if it is even possible with this engine.

I really hope someone can help me with this. Already thankfull that you've read this all so far ^^

Thanks

BTW : Texels are pixels, right? It confuses me

A pixel is the RGBA component of a scene. A texel is a pixel of a texture.

Genesis3D is built on a BSP. BSPs are not made for outdoor worlds (or modern rendering methods for that matter). If you want to make a large outdoor world, you will have to write a terrain renderer in Genesis. You can do this without modifying the engine by using geEngine_RenderPoly().

In short, what you are asking to do is very doable, you will just need to modify RF to do it. The way to do it is to create a terrain renderer, tell Genesis3D to use a NULL world and render the terrain instead. You will not be able to use the world editor for this as the world editor only supports the use of the BSP.

If you require large outdoor scenes and you don't want to do additional programming, have a look at OGRE or NeoAxis.

Also, an entity is not necessarily a model. An entity can contain a group of models. So you can have pretty much unlimited actors (barring system performance), but only 255 entities.

Excellent, thanks paradoxnj!

Right, I know all about BSP mapping but only for goldsource. I understand both RF and GS are using it the same way. Source, the engine for HL2, is also BSP but suitable for outdoor scenes as well. I understand I cannot compare RF to Source.

Making a rendered world in NULL world, as you descibe it, is beyond my capabilities. I have a fair understanding of the effect (older Delta Force games, etc.) and I assume all is done entirely in script/code and I am more of the creative side.

I will take a look at those other engines. Do you happen to know if they have a high learning curve?

im just started using neoaxis, and it has not got a lot of documentation but the demo maps have everything you need to get started. the forums are as good as rf, i would have stuck with rf but needed to make large outdoor levels like yourself. so do try it at least

Thanks! I will!

actually the way im going to do it is by making a terrain mesh and slicing them into different meshes in the modeller. then i export each segment as different .act files and create LoDs for each segment

Wow, this really works or are you going to experiment with it? Looking foreward to your results.

experiment, i havent actually tried it. it seems like it would work tho

Of course it does work. I am preaching this for quite a time now but darksmaster is the first one i've seen who tries it. I've also done it. The main map for Towers of Trembolon cnosists of a few meshes, not just one big mesh. I have an old image somewhere... (yeah it's old, it's from the time i 'invented' this technique)

Hm... i think i cannot find it. But this one is the same terrain, newer picture, i still have it on my computer. Or i HOPE i still have it. Loved this terrain, but the ugly system crash that caused me to start my project over again ending in the ToT demo might have destroyed it.

http://www.realityfactory.info/forum/vi ... ain#p11762

As you can see, framerates are still good even if you take into account that it is a farily big terrain (3,8k polys, that's much collision to be done)

EDIT: YES, I still have it. It consists of 8 actors.

Excellent, thanks the both of you. Could you please share the source files of that whole setup, Jay? I will be most grateful!! Don't worry, I will not use anything of it, I only want to take a little peek at it.

Something like this would render more efficiently if Genesis supported hardware transformed static geometry. I've decided I need a break from Jet3D for a while and dove into the Genesis code (specifically the OpenGL driver). Static geometry would be very easy to implement. Static geometry would be defined as geometry that does not ever change. This way you can put it in a vertex buffer, never modify it and just render it every frame when it's in view. Unless terrain is destructable, it's never modified.

My design for static geometry in Genesis would be as follows:

• Add CreateStaticGeometry(), RenderStaticGeometry() and DeleteStaticGeometry() function to the drivers. The create function would return a geRDriver_StaticGeometry handle which can be defined differently for each driver (like geRDriver_THandle). The RenderFunction would...can you guess...render the static geometry. Delete function would free the VB/VBO.
• Create a code module in Genesis for geStaticGeometry. This should manage the vertices, indices, textures, and driver handles for the static geometry (like geBitmap).
• Add geWorld_AddStaticGeometry() and geWorld_RemoveStaticGeometry() functions to geWorld. The world should manage all geometry.
• Modify the geWorld_Render() function to include rendering static geometry.
• Modify geWorld_Collision() to take static geometry into account in it's collision calculations.

I'd like opinions on this. If no one picks up the task and I'm done bringing the OpenGL driver up to speed, I may do this.

I've been playing around with this for some time now. I did it in level 1 of Talisman. Everything is actors (SEP.S with no collision) and the only geometry in there is a few clip brushes for collision purposes. Even the grassy area's are actors. I'm still playing around with terrain for level 3 cos I want hills and such like. The problem I'm wrestling with at the moment is trying to get water areas semi transparent. I can achieve it to a certain extent with SEP's but its not satisfactory and it wont work at all with static mesh. But it is definately the way to go. I am using a free program called L3dt to generate the heightfield and textures and then using that heightfield in T2 to create the mesh (L3dt generates too many poly's but the texture is great wheras T2 can create a mesh any size I want and will split it up quite nicely, but its own textures aren't that good). By the way Tabulanis did this with his demo too a few years back, he was an absolute whiz with textures, I wish he was still around.

I don't have all source files of that setup anymore, i only have the actors. If you'd view them with actor viewer, you could look at them to see that they fit together. Also you could add them into a big level as staticmeshes, scale 1000 i believe, at the exact same point. ColCheckLevel is 2, and VisChekLevel is 1. UseFillColor is true for more speed up (disables lighting on the terrain, making it one color) And fill color was 128 i think. All the CompLight options are false. Backfaced is false, rotation and origin are the same for all actors.

I'll see if i can upload them somewhere and then pm you. I am going to modfiy them a bit ayways before adding them into the game. (I want to have effects like smoke over the volcanos etc. For that i need bones to add them at the position i want).

Nice! Thanks Jay!