work while we wait?
work while we wait?
is it possible using irredit to work on 3d scenes and be able to use them when RF2 is ready and just import?
i could see this as making the game almost ready to use with RF2, as by the time it comes out you will have made the 3d world and thought of the story, made animations for models, and so whats left is to put all of these items together to make the game? then shove in the stuff that only RF2 will make easy like moving platforms and such.
i could see this as making the game almost ready to use with RF2, as by the time it comes out you will have made the 3d world and thought of the story, made animations for models, and so whats left is to put all of these items together to make the game? then shove in the stuff that only RF2 will make easy like moving platforms and such.
*GD*
Your best bet would be to use RFEditPro; since there will be backwards compatibility, that way you can work in RF1 and then when RF2 is released you can import it.
RF2 site: http://realityfactory2.sourceforge.net/
RF2 tasks: http://sourceforge.net/pm/?group_id=179085
RF2 tasks: http://sourceforge.net/pm/?group_id=179085
Thats pretty much what im doing. Making a beta of the levels in RFeditpro, Im also though saving two of each texture (one highrez and one RF1 rez) also all the models im making with high poly and RF1 poly that way when RF2 cums out, ill have the whole game i just have to update all the stuff 

My Deviant Art - http://black-crusader.deviantart.com
but thats what i mean, hi polly models and stuff, now RF2 will handle everything completely different, no bsp so it will remove stuff you cant see, im not sure exactly how it works but the fact that you can import ms3d files suggests to me that it uses other methods.
what i ment was actualy create entire levels in something like ms3d where you can optimise polly count and also can build complex level geometry that isntrestricted by primative shapes.
RF is great but can be a little restricting with level geometry thus needing new ways to create it thats more suited to RF2
i have projects going that i know wont be ready any time soon and knowing that can aim for RF2 with it.
what i ment was actualy create entire levels in something like ms3d where you can optimise polly count and also can build complex level geometry that isntrestricted by primative shapes.
RF is great but can be a little restricting with level geometry thus needing new ways to create it thats more suited to RF2
i have projects going that i know wont be ready any time soon and knowing that can aim for RF2 with it.
*GD*
a good modeller and also level creator is DeleD. You could try that one for the levels as it can export to *.X files (which can be loaded by irrlicht and so, i suspect, by RF2). It also can produce lightmaps which is not very common with free modellers.
http://www.delgine.com/index.php?filena ... 660ede2d31
http://www.delgine.com/index.php?filena ... 660ede2d31
Everyone can see the difficult, but only the wise can see the simple.
-----
-----
Creating levels using ms3d (or any modeler) and exporting to a raw .x or etc file is a Very Bad Idea. Let's say you had two chairs that are identical in your level. When you save, those chairs would be saved twice, once for each chair, because the modeler cannot tell that it is just a chair repeated twice in the scene. Multiply that with trees for a forest level, for instance, and you could have the level take forever to load because it thinks it is loading 600 different trees instead of 1 tree and placing/rotating/scaling it differently 600 times. Many different reasons this is a bad idea.
Thats why we would use a level editor. Model a desk, export it as desk.whatever, model a chair, export it as chair.whatever, model a door, export it as door.whatever. New level, make hollow cube, add desk.whatever, add 2 chair.whatever's, add door.whatever, and run is the best, most optimized way.
Thats why we would use a level editor. Model a desk, export it as desk.whatever, model a chair, export it as chair.whatever, model a door, export it as door.whatever. New level, make hollow cube, add desk.whatever, add 2 chair.whatever's, add door.whatever, and run is the best, most optimized way.
RF2 site: http://realityfactory2.sourceforge.net/
RF2 tasks: http://sourceforge.net/pm/?group_id=179085
RF2 tasks: http://sourceforge.net/pm/?group_id=179085
i can see what you mean, and i understand it.
what about the layout of the levels tho, im trying to make a city style level with lots of different buildings, this is something you would normaly create in RF because of bsp reasons and optimisation, so as long as we dont use the same thing twice we can make our world, then when RF2 is ready import the objects that are used more than once to there relevent locations
what about the layout of the levels tho, im trying to make a city style level with lots of different buildings, this is something you would normaly create in RF because of bsp reasons and optimisation, so as long as we dont use the same thing twice we can make our world, then when RF2 is ready import the objects that are used more than once to there relevent locations
*GD*
@AndyCR: What you say is right, but if we had 600 scene nodes for 600 trees this would kill performance too, wouldn't it? Or are you going to prevent that somehow? (Maybe mesh/scene node merging or something like that?)
I mean, even if RF1 is completely different from RF2, when i have 120 StaticMeshes for trees they are definitely MUCH slower then when i used just 4 or 5 meshes (so they can be culled and not everything must be rendered)
I mean, even if RF1 is completely different from RF2, when i have 120 StaticMeshes for trees they are definitely MUCH slower then when i used just 4 or 5 meshes (so they can be culled and not everything must be rendered)
Everyone can see the difficult, but only the wise can see the simple.
-----
-----
what he is saying i belive is that when say a tree is renderd more than once in one scene then the computer would load the same tree twice taking up double the memory because the computer wouldnt realise that its the same as the one it just loaded. it wouldnt render all 600 trees at once, it would render a few that can be seen i belive, its just saying if you have 10 trees in view at any one time and they are the same as each other just differnet position, then instead of loading 10 different trees it loads the one and place them multiple times.
*GD*
Yes but the problem is that maybe with 600 trees (even if they are not rendered) it is an immense work to cull every tree against all trees that are closer to the camera then the current tree... also the engine has to go through all 600 objects one after another even if they are not rendered anyways and i am not sure if this is that good for performance...
But maybe i am just talking rubbish so i will test this myself (under Irrlicht); i will just add 600 scene nodes of trees with a low FarClipRange (to prevent them from being rendered) and then look what happens...
EDIT: Ok i was wrong. A few test results:
(all trees are seperate nodes)
25 trees: 244fps
100 trees: 214fps
400 trees: 194fps
1K trees: 157fps
4K trees: 82fps
16K trees: 27fps
Note that this is not because of the actual rendering, i almost totally disabled the rendering by making the FarClip plane very near to the camera. It was a test about how fast irrlicht handles scene nodes, and it seems impressive enough for now. So we should not go over 1 thousand Entities in RF2. That's no problem for me. I am not sceptical any more
But maybe i am just talking rubbish so i will test this myself (under Irrlicht); i will just add 600 scene nodes of trees with a low FarClipRange (to prevent them from being rendered) and then look what happens...
EDIT: Ok i was wrong. A few test results:
(all trees are seperate nodes)
25 trees: 244fps
100 trees: 214fps
400 trees: 194fps
1K trees: 157fps
4K trees: 82fps
16K trees: 27fps
Note that this is not because of the actual rendering, i almost totally disabled the rendering by making the FarClip plane very near to the camera. It was a test about how fast irrlicht handles scene nodes, and it seems impressive enough for now. So we should not go over 1 thousand Entities in RF2. That's no problem for me. I am not sceptical any more

Everyone can see the difficult, but only the wise can see the simple.
-----
-----
Well, isnt there going to be a level editor coming out with RF2? In that case i think all we really need to know is where we can find anoother app that can do the same stuff and export as the rite file type for an RF2 level, while also treating models and static meshes like brushes (not loading them like a million times) and then we could use this to make the levels for RF2 in? 

My Deviant Art - http://black-crusader.deviantart.com
Correct; that application is RFEditPro.
RF2 site: http://realityfactory2.sourceforge.net/
RF2 tasks: http://sourceforge.net/pm/?group_id=179085
RF2 tasks: http://sourceforge.net/pm/?group_id=179085
Basically, there will be a lot of translation going on behind the scenes. Stuff like shaders etc. would have to be made using the RF2 toolset. For shaders, you would most likely be able to use the name of the texture in rfeditpro as the name of a material, which could contain just a normal texture or any shader. By default RF2 would extract the TXL file into the RF2 folder and assign the resulting textures. I have no plans to retroactively add features to the old RFEditPro.
Some entities would be handled by Python, while a very few would be handled by RF2 itself (Light, StaticMesh, DynamicLight, etc.). It would work something like:
Create game in RF1
RF2 comes out
Use RF2 import utility to translate RF1 resources into RF2 ones and convert levels
RF2-RF1 scriptset would handle resulting game; can now be extended like a more elegant scripted pawn for everything
I will be using the RF1 RFEditPro for the first RF2 test levels, in fact. (RF2 will bypass the compile process and import the resulting raw 3dt files)
EDIT: I may have misunderstood what you said, sorry. If you meant that if we want to use RFEditPro as a level editor, yes, we would have to modify it, but we will be rewriting it anyway.
Some entities would be handled by Python, while a very few would be handled by RF2 itself (Light, StaticMesh, DynamicLight, etc.). It would work something like:
Create game in RF1
RF2 comes out
Use RF2 import utility to translate RF1 resources into RF2 ones and convert levels
RF2-RF1 scriptset would handle resulting game; can now be extended like a more elegant scripted pawn for everything
I will be using the RF1 RFEditPro for the first RF2 test levels, in fact. (RF2 will bypass the compile process and import the resulting raw 3dt files)
EDIT: I may have misunderstood what you said, sorry. If you meant that if we want to use RFEditPro as a level editor, yes, we would have to modify it, but we will be rewriting it anyway.
RF2 site: http://realityfactory2.sourceforge.net/
RF2 tasks: http://sourceforge.net/pm/?group_id=179085
RF2 tasks: http://sourceforge.net/pm/?group_id=179085