DX8 progress

Good news! I just happened to order and receive the DX8 sdk a couple of weeks ago. Your timing is good.

PRO Edit is now working under PR 4b2. LStudio 4 editor is working but the landscape engine itself is not drawing things properly yet.

I''m currently adding a new library archive/file system. This will let you add in custom archive formats like zip or rar.
In order to do this I am making all my own file reading functions (fread, fgetc, fgets, etc) which work from a buffer in memory. This way you can use whatever method you need to get the data in memory (allows compressed format) and PR will be able to use it.

I''ve created some functions that let you register file extensions with a set of functions for reading them. For example PRLIB_OpenLibrary ("data.zip") will figure out that it''s a .zip file from the list of registered extensions and set up the appropriate function pointers for getting files out of it.

I''m pretty happy with the way things are turning out. But you won''t see a beta for a while yet until I have all the core functionality done. I want to really clean up the interfaces as much as possible before I start doing anything more complex.

Doesn''t proedit ship with source ?

saved directory in proedit would be really nice, i''m glad someone brought it up.

also would be /really/ nice to see some improved collision detection functions. i hope and hope that one day i will see a

PR_DWORD PR_EntityCollidesWithEntity(entity1, entity2);

seems like if i shelled out all the cash for this API, i deserve it, no?

I often feel like putting all the polytopes on a big boat, sailing it out in the middle of the ocean and sinking it.

in ASM, to detect collision i would take the two objects loaded into memory and compare them, and if any non-transparent pixels overlapped it would terminate the loop and return a TRUE.

DECLARE FUNCTION GX_Collide(x1, y1, obj1, x2, y2, obj2) AS BOOL

now, i can understand that this isn''t even close to what needs to be done now that objects are in 3d space, but it would be really nice to have Mr. Egerter program us a really simple-to-use function to detect collision. i have enough stress programming the game engine, i don''t want to have to worry about the API slowing me down (which it hasn''t until now).

-Rich

How much precision do you need? It''s not a good idea to compare every polygon against every polygon in the other object.

I could write a routine that does that, but people would abuse it and then complain the engine is slow

There are many different ways to do collision detection. I''ve only implemented the ones that are fast and can apply to the things I''ve tried to make (spherical, portal, polytopes).

Chris

guess your right.. full object comparison would be slow as mud. what commands would be used to find the 8 outermost points of an entity and use those to create a bounding box. i looked at the examples, but they were kinda confusing. .. .. and what is portal? i looked at the example, but i''m not sure what it was trying to prove. sorry for my lack of knowledge, but i''m new to the 3d scene.

-Rich

Well .. the collision examples are surely confusing .. since powerrender is a 3d Engine it must have a much more easier funtions to detect collisions.

Maybe everybody can poolin suggestions as to how collision in Pr4 should be like

It would be nice to be able to create a polytope on the fly when the pro is loaded. Perhaps even a new routine to create a polytope from a loaded pro and be able to specify different types of the polytope like bounding only for complex models and exact polytopes for simple geometric models for instance. I find having to make a .hit file cumbersome and a waste of space.

All is fair in love and war

OK PR4 has been delayed for 4-6 months while I research new collision detection techniques

Generating polytope from an object is not a good idea. Say you had a cylindrical stone statue with a detailed horse at the top.
The engine would analyze that and make a ton of polytyopes, where a person would just make a cylinder.

It is much faster (at run time) to make the polytopes in the modeling program. I also have doubts that it could create proper polytopes from a polygon soup, especially when you need to walk around inside it properly (ie one of the warehouses from Counterstrike for example). The walls could be a single poly in thickness but the polytope would need to have thick walls...

Chris

A colision system that allows to entities to slide or bounce off of each other would be nice. Does anyone have a quick and dirty way of doing this. I was thinking of like finding the direction vector of the moving entity, and detecting for the face(s) of an opposing entity that would collide with the face(s)of the moving entity in relation to the dir vector. This would eliminate the need to detect collision with all the polys of two given entities and give the programmer more precision as to where the collision exactly occured at, for appropiate reactions such as sliding, bouncning, explosions...etc

Some time back I had seen in a game demo ..a red laser bean from the held gun gives an idea as to where your gun is aiming.. this establishes precise collision point on objects. How can we implement this in PR. On the terrain it is pretty simple ..but on other objects how ?

What if we had a simple routine that could associate a very low polygon version of an object with the real version of the object.
The collision routines would do checks against the low polygon versions while the rendering engine would render the real objects.

I haven''t even started to try and understand the current collision system yet, so I don''t really know what I''m talking about, but it would really be nice if I could just create two versions of my scene -- one showing a finely detailed statue, and one in which the statue was just a cylinder or cube.

I''m sure this can probably be done with the current system, but I haven''t really been able to grasp the whole "intersecting rays" concept.

"What if we had a simple routine that could associate a very low polygon version of an object with the real version of the object. "

xGambit, that is fairly standard collision detection. What you''re describing is commonly referred to as a polytope, which is basically a low-res version of a mesh used for collisions, occlusion and other things.

"...it would really be nice if I could just create two versions of my scene -- one showing a finely detailed statue, and one in which the statue was just a cylinder or cube. "

A.k.a. bounding volumes. ;-) In this case a bounding-box (either oriented [OBB] or axially aligned [AABB]), and a bounding cylinder (always axially aligned... to expensive otherwise).

IIRC, Unreal uses AA cylinders for coarse collision detection, then uses a either per-bone OBBs or a low-res polytope. I''m not sure which as I''ve not worked with it, just heard people talk . Chris probably knows, since he''s at DE.

When all of the planned features are implemented and I''m happy with it. I don''t have any timelines for PR4, I just want to make it as good as I can. I wouldn''t be concerned with when it is completely finished. 3D engines are never really finished
I want to get out a version that people can start using with DX8 and be able to add features without breaking the old stuff.