Forge CE: Tracing 'n Stuff
by, October 26th, 2010 at 12:24 AM (1918 Views)
Uhhhhhhh Hi! Just got home from work and boy are my dogs barking! I wasn't planning on doing a blog tonight but what the hell. I haven't really had time to work on Forge the last week but there are some new stuff going on in my code and in my brain.
Ray Intersection with Geometry
So in Forge when the mouse cursor ( center of the screen ) rolls over an object model, it changes the menu to include object options exactly how it is done in Reach Forge World. How is this done? Well, in Reach I believe they use ray-plane intersection determination with the object geometry. Imagine a ray that starts from the center of the camera and points forward into the game world. Through mathematics you can determine if this ray is intersecting certain things like bsp or object geometry so you can know whether or not you are looking at a certain something and/or if this certain something is visible to the camera. This type of method may also be used for collision among other things.
In my Forge code for CE, I was originally converting object world space coordinates to screen space coordinates and determining closest object that way (thanks to Abyll). The problem however is even though objects may be closer to the center of the screen than other objects angle wise, that object may or may not be closer distance wise. I would accidentally grab hold of objects that were way across the map because they were closer in screen space, not so much in world space in distance. I thought writing functions to calculate closest object by distance and closest object by angle would solve this, but it was a waste of hours of time and is very slow.
Now in my code, I am currently using a ray-sphere intersection method. In the s_object_data struct in OpenSauce, there are variables for bounding position and bounding radius. The bounding sphere radius is just enough to encapsulate the entire object and nothing more. So since each object has unique bounding information, I can more efficiently and easily determine what objects I am looking at. In my intersection function when I iterate objects, I also determine which object is at a closer distance out of the object spheres my ray is intersecting with. (The ray origin and direction is the camera position and forward vector by the way.) This is very fast and works so much better. I am happy with it. Eventually I will move onto something even better: ray-plane intersection - to be even more accurate and so I can do visibility determination and eliminate objects that aren't in view through the bsp geometry! Halo has all this data, but I have no idea how to make use of it yet.
Bounding Boxes & Markers
I recently saw a video tutorial by Siliconmaster about how to fix phantom bsp errors. In Sapien I thought it was REALLY cool that they had (pft, pink) bounding boxes to show the phantom bsp. I believe in Spark Edit, they used these also but I can't remember exactly. I want to include this feature just for the coolness factor and also it will help me learn how to draw my own 3d markers in the game world. The markers I am talking about will 'mark' where the object spawn points and game flags (koth, race, ctf, oddball, etc) are. Years ago when I first started this project I was doing this in 2D and it was a terrible idea and it's very ugly. To see what I am talking about, here are screen shots from a few years ago:
See those ugly ass boxes? Of course they aren't scaled and to size so they looked terrible anyway. Making them 3d to surround the objects / spawns so they appear in the game world would be epic. So over the next few nights after work I am going to be researching this phantom bsp function. So far I have seen they are drawing 12 separate lines for the edge but haven't really looked further than that code or deeper into it yet. If I knew more about rendering in d3d, this wouldn't be so hard, but I don't really want to be a d3d master just to draw some markers in the game, although I really want to be a game dev in my future. I need to go back to school, soon.
The spawn point models in Reach are sweet. I. want. that. bad. It'll get there.
My other idea was to just create custom model markers and their tags, then include these tags in the model rendering process in the engine without actually creating the object in game so it doesn't have any attributes other than geometry so it doesn't interact with the world. This seems easier and I might try it out but first I gotta figure out more of the rendering code and I how I can accomplish this. This calls for a talk with FireScythe if he even cares. I don't think anyone even cares at this point, I haven't received any feedback other than from dwood -- shoutout by the way, I call him DWORD LOL!
What do you guys think?
Anyway I am tired and done writing for now until next time. See you soon.