Reality Factory

Well, first of all, I have been keeping you guys in the dark yet again! I should be ashamed of myself, and I am.

======================================

RF2 is being rewritten.

The reason? Irrlicht has proven completely unsuitable for out project. We are switching to OGRE, as well as changing other things, including the scripting framework - it is still Python, don't worry, but we are now using Boost::Python instead of the Python C API, which results in much faster development times and much more readable code.

Here is a basic list of why we are switching:

Not working with parallax mapping on OpenGL or Direct3D9, only Direct3D8
Ugly interface, split interfaces for tangent and non tangent generated models
Horrible art path
Slowness with large scenes
Very ugly shadows
Lots of ugly hacks needed to get a level editor running correctly - I had developed a nearly usable level editor (more of a scene graph editor really) called Envision, but cannot use it due to engine switch
Needs ugly hacks above to get it to work with wxWidgets on all platforms (our GUI library)
Not very object oriented; ugly hacks needed to make it look good in Python
No directional lighting (ie spotlights, non-baked sunlight)

I spent more time figuring out whether something was an Irrlicht bug and trying to fix it than I have learning OGRE so far. RF2 will be infinitely better because of it.

======================================

RF2 is now hosted on SourceForge! Check out the site at http://realityfactory2.sourceforge.net/ , and the project page at http://sourceforge.net/projects/realityfactory2/ . The hosting is used mainly for information for those outside the RF community.

======================================

Public CVS and, when I get it set up, Subversion access! Up to the minute code from RF2. Grab the code, build it, and check it out at any time using readily available, free utilities. Soon, task lists which tell exactly what is being worked on, who is working on it, and about how long it will take. Coders out there, feel free to take a stab at any of them, hint hint - if not assigned to a user, they are up for grabs, and once complete they can be submitted via the patch tracker system on the project page.

You can also view the old source in the SF.net project page's Browse CVS section (note that I might bring it down once the new source is up).

======================================

More open development process due to the above! No need for status pages that are half a year out of date, you can look and see yourself at any time! That means, for instance, that if I haven't changed the source in a week, you can give me a much-needed poke or two!

Also, a bug tracker! Submit one, and watch me jump around swatting it!

Soon, mailing lists to keep up-to-date with RF2 news! Use the mailing lists to shape the path of RF2's development and RF2 itself!

======================================

When done, useful developer documentation! Grabbing the source, compiling, and testing it out should be pretty simple, and will be documented, as should adding new features on the task list!

======================================

This should help development time considerably. A more organized structure and help from others should speed things up nicely. Not everything is up yet, but it is going well. Comments?

Comment - "WOW"

That sounds like a massive undertaking (re-doing so much) but as you say, It sounds like it will be for the best in the long run...

Im checking out the site now, and it looks amazing, also the possibility of speeding up development is always good news! The ability for developers to watch your progress is also aWsome! And is a very exciting prospect for me, I've looked at OGRE in the past and it is a very impressive engien and I'm glad we'll be able to use it. I still need to work on learning python, but you say that there are different um versions of it?

Boost::Python instead of the Python C API

can you just clarify for me, is there a huge difference in these? (i.e. if I use online sources to try and learn the syntax etc. I wont be learning the complete wrong thing?)

Well its good to hear your making progress and its all good news.

Thanks

so waht does this mean in the engine? will compatability be an issue now? what file types does it support?
you got a link to the graphics engine to take a look at its stats

********edit*********
ps. is it still 2010 or is it now delayed?

The only change to Python is the one developers deal with. Those who do not modify the C++ source code will notice no difference (except maybe less bugs). It's just Python. The way the development of RF2 goes is all that is affected.

Yes, it means that the only natively supported mesh format is .mesh, Ogre's format. This is, however, a good thing. Irrlicht's file formats, I did not know at the time, may be numerous, but they are also incredibly buggy. I had been unable to find a consistent way to get a mesh out of Blender and into RF2 without issues of some kind. With Ogre, I just hit export, ran it through the compiler, and it just worked. Backwards compatibility plan has not changed.

Yes, I am still targeting 2010. However, having the source code means you can have RF2 "released" at any point. Versions from that point will be named after the revision in SVN. For instance, if you get RF2 as of the 100th revision, it will be RF2-r100. Whenever its to the point that it meets your needs is whenever you can start using it, though unless your needs are incredibly small it won't begin to meet them at the moment.

Specs: http://ogre3d.org/index.php?option=com_ ... &Itemid=62
Screenshots of interest:
http://ogre3d.org/index.php?set_albumNa ... _photo.php
http://ogre3d.org/index.php?set_albumNa ... _photo.php
http://ogre3d.org/index.php?set_albumNa ... _photo.php
http://ogre3d.org/index.php?set_albumNa ... _photo.php
http://ogre3d.org/index.php?set_albumNa ... _photo.php
http://ogre3d.org/index.php?set_albumNa ... _photo.php
http://ogre3d.org/index.php?set_albumNa ... _photo.php
http://ogre3d.org/index.php?set_albumNa ... _photo.php
http://ogre3d.org/index.php?set_albumNa ... _photo.php
http://ogre3d.org/index.php?set_albumNa ... _photo.php

do you know how many polys we will be able to have in one scene now. has it changed much from irrlitch?

Irrlicht is good but I'm glag your going for ORGE, it's a better engine.

I've always loved the Magic of Stonehenge Demo. you must try this one.
http://ogre3d.org/index.php?option=com_ ... lecatid=25

Thanks!

No, the general polygon count ability shouldn't change much.

Yeah, that demo is quite good.

A couple of Ogre rendered engines

http://neoaxisgroup.com

also Dungeon Hack
http://terrymorgan.net/dhfaq.htm

Wow, OGRE has really grown up since i last saw it. the first screenshot you posted is very impressive.

That's good to hear. OGRE is way better (i mean cleaner, unbuggy code) than Irrlicht from what you hear. I once heard that Irrlicht uses the DrawPrimitiveUP() command for its rendering - That's ok for particle systems and HUD items which don't have much polys per item (2 to be exact) and also have to be updated every frame, but for things like StaticMeshes it is just an ugly hack and costs time.

the first screenie the hud is bf2's hud

Yes, the person who created it used the BF2 hud, but modeled the tank himself.