Reality Factory

I remember running an ogre tech demo once that had water that was rendered as a real time self modifying heightmap rather than an animated shader. The result was the most realistic water ever, and it somehow didnt take up too much processing power. That would be nice to see in rf2!

I think AndyCR can best answer your question in more detail, but the consensus seems to be "Whatever Ogre can do, RF2 will be able to do".

My only requests are physics and the ability to have huge maps !!!

I also want the scripting system to have direct access to the physics engine, allowing a weapon to detect and change the position, orientation, model, and texture of any object, player, npc,or other entity in the game world. This would allow for weapons like the:

Physics Gun
Gravity Gun
Nuke
Suck Cannon (Vaccum/Rocket Launcher)
Polarizer (Magnet)
Morpho-Ray (Mutator)
Repulsor Field
AND MORE!

P.S I want all rendering to be done by real time ray tracing!

Might I suggest the addition of french fries?

I remember running an ogre tech demo once that had water that was rendered as a real time self modifying heightmap rather than an animated shader. The result was the most realistic water ever, and it somehow didnt take up too much processing power. That would be nice to see in rf2!

It's possible. That water is actually just using an algorithm found outside of Ogre itself. I'm not yet sure whether that would be up to scripting or the shell, but I would probably put it in the shell itself.

I don't know if it's already been said, but it would be great to be able to change the player's or enemies' models in mid-game. That way if for example you're making an RPG, you'd be able to make a (Pawn?) for every single Summon or Spell that needs a model, and you wouldn't need one for every model.

You don't even need to do that now. Just make the pawn a very small thing (so it won't be noticed in the game) and attach a pawn weapon to it (or with the new release another actor that blends with its motions)....

I don't get it, Jay. I mean instead of having 50 pawns for each model you want in the game, have 1 or 2 that can switch from one model to the other.

Do you want them to all think alike? How do you account for that in script? How and when would you change the model?

he says that it would be great to be able to use 1 or 2 pawns to attach to a lot of models, like saying 1 pawn for all weapons, or spells...

I know what he is saying...that is logically impossible. Weapons behave differently. Scripts not only define pawn properties, but logic also. The scripting system in RF2 is very different from RF1.

So you're saying if for example I'd want my character to transform into various creatures I'd need God knows how many pawns (or whatever they are in RF2) one for each, instead of being able to script (or whatever you do in RF2) all their behaviours into one?

Or imagine in an RPG I've got a spell or whatever that makes a... let's say... hand, come out of the floor and punch or squash an enemy, if what I say were to be possible, I'd use a pawn that I've got prepared for various spells turn into that hand, and do whatever it does, instead of have 50 odd scripts, one for each spell.

Or say I'd want to make a gun that freezes enemies into ice like in Bioshock. Instead of having a different pawn to appear where the enemy was, but with a "frozen" model, if what I say is possible, I'd simply tell the enemy to change it's model to the frozen version. This can be done by simply changing it's materials, but if I'd want something more realistic...

No, that's not how it works in RF2. A "pawn" in RF2 can have any number of objects attached to it, be it actors, lights, etc., and control them from one or multiple classes if desired split into whatever file structure you wish. There's groundwork for changing a mesh in RF2 already (if I'm not mistaken RF2Actor has a SetMesh() method), it's just not implemented in scripting because there wasn't much use for it until now.

AndyCR wrote:Might I suggest the addition of french fries?

Was that your response to my ray tracing joke?

P.S. Ray tracing info: http://www.sgi.com/pdfs/3883.pdf

You posted a list of stuff that was all up to the game programmer (not the shell) to make.