Reality Factory

ok here goes, im not sure on how to go about doing it, however a feature request is to be able to create a seperate document for texture co-ordiantes.

my reason for this is so you can have multiple models, multiple textures and for each of those textures they have a uvmap for each model that you apply it to, so say you got 1 model and 10 textures, you dont need to have 10 copies of the model, all that would be needed is 1 model 10 textures and the co-oridnate file.

why you may ask, simple reason is so that you can have the same texture positiond differently, use as many texture sets as you want per model without having lots of the same model taking up memory and similaly with textures, as it is my current understanding is that the co-ordiantes are copied with the model and thus limits each model to one set of textures.

im not sure if this is possible or if it will get too complicated, it may already be implemented within ogre it also might not be possible and down to ogre itself and not RF2, however it is a feature i would like (and i would think many others would find useful) and thought it wouldnt hurt to ask.

What I meant was that I wanted to be able to move a pawn around using scripting. Some engines don't let you do that. Hopefully RF2 will.

Sorry if an inquiry has already been made to this effect, but what is the status of the physics engine in RF2? Will it be a 3rd party engine or are you working on it yourself?

I'm back from the trip now.

Destron wrote:Sorry if an inquiry has already been made to this effect, but what is the status of the physics engine in RF2? Will it be a 3rd party engine or are you working on it yourself?

I'm going to be using Bullet for physics. It's being used for collision detection now, and I'll be using it's physics capabilities as well.

How about ray tracing for the models, a program less than RF can do that http://www.ultimate3d.org. In other words, make everything have the polygon collision of a static mesh. It might be slow, but to fix that have it only do the test within a certain distance (the player's height?), again, like the website above.

Scott, just fool around with the actmaterial entity, that will get it changes.

Edit: Double post deleted by bernie.

Ray tracing is a rendering technique...not a collision detection method.

paradoxnj wrote:Ray tracing is a rendering technique...not a collision detection method.

He probably means a ray-mesh intersection test which is commonly called ray tracing.

That is ray collision. Tracing usually refers to drawing.

Allanon, you are right. (unfortunately I have little experience with terminology, just know what it does) A program (Ultimate 3d, an extension really) made to interact with a small program (Game Maker) that has ray tracing. If it can be done with that little engine, why not for RF2 (in whatever programming language is being used to construct it)?

Let's stop calling it ray tracing as that is confusing. The correct term is ray collision or ray-mesh intersection. Genesis already has this. If you are looking for per poly collision, RF has that with statis meshes but it's not very efficient.

Yeah, ray collision.
Why not just do a ray collision test only within a certain radius of the player? (or does it already do this?)
Apply it to pawns and players perhaps and have the radius be the player height.

You usually do ray collisions with a bounding box or a bounding sphere. Genesis does this with a bounding box. Ogre uses bounding boxes or bounding spheres. RF2 will use what Ogre uses plus a physics library for collision response.

GMer wrote:Why not just do a ray collision test only within a certain radius of the player? (or does it already do this?)
Apply it to pawns and players perhaps and have the radius be the player height.

Because that would bring little to no benefit. Testing if the player collides with a vertex or a face is little difference to testing if the player is in a certain range of the vertex / face. I tested this. I used a distance checker in the RF StaticMesh collision code and it had little to zero effect.
The human eye sees that an object is near or isn't near to another, but a computer has no human eye and therefore must compute it all...

If RF2 uses a physics engine to do the collision i trust it that it can do per-poly-collision. And per-poly-collision using the physics engine will enable the physics engine to work properly, so i don't see any point in it to disable the physics engine collision and use an algorithm of our own. And then try to get it to work with the physics engine (what is done with physics in RF1)

I also trust the physics engine that it uses some sort of tree (Octtree maybe?) to optimize its speed.

Actually, I was thinking something along the lines of this:

E.G. You have a big monster, you shoot his arms and body he doesn't die. You walk up his arms (while they are moving) and shoot him in the head.

Basically, why not do a collision check similar to a static entity mesh on a pawn?

More accurate shooting, ability to dive in between the legs of a monster to safety!

THAT WOULD BE AWESOME!!

Somebody played Shadow of the Colossus. This will be possible.