I was reminded the other day that our zone geometry files are sometimes incomplete and contain holes (missing data). The new line of sight system I am envisioning (one loosely based on the watersheding technique) requires a complete zone geometry file. So, before I jump into implementing a new LoS system, I need to verify that our geometry files are indeed complete, which requires building a Direct3D application to load, view and patch a zone's geometry data.
I have never written a D3D application before and it seems to have a bit of a learning curve, but I am excited to learn something new. I am hoping that even if our zone geometry files are complete, I can expand this application to support laying pathing nodes and roam boxes.
Subscribe to:
Post Comments (Atom)
Talk to wizzel. He can jump start you about 6 months (only using opengl) for doing things with zones. I can point you to all the info for opening/deconstructing the client files too if you need. Frankly you shouldn't need to even visualize the zone if you can read/analyze the geometry data.
ReplyDeleteD3D is actually really easy to use and my zone viewer is just about done (just need to match my camera controls to the client's).
ReplyDeleteI am mostly curious to see if there are actual holes in the geometry files and not just oversights in EQEMU's LoS system. I have only looked at a few zones, but AZone's dumps look great.
You aught to go full out and just make it a client. Just saying... ha
ReplyDeleteIt briefly crossed my mind!
ReplyDeleteThe vertex data dumped from AZone is complete, but EQEMU's algorithm still fails to detect collisions in many spots. I am inclined to believe they are not traversing the *.s3d's tree properly.
Also, for whatever reason they had, V.I. chose to use quadtrees instead of octrees to partition the 3D space. I think I am going to investigate remapping the vertex data with octrees, which should speed up LoS checks in complex zones. I guess V.I. figured that an abundance of geometric faces in the third dimension (z-axis) would be rare, yet when you look at a zone like Velketor's Labyrinth, this is obviously not true.
In any case, none of this will be necessary if I can get my original idea for a new LoS system implemented. I failed to realize that--even with complete geometric data--the regions of playable space and non-playable space are not guaranteed to be separable because areas exist the blend these regions together (e.g., the areas behind zone lines typically spill out into non-playable space). These scenarios makes it much more difficult to separate these two regions.