• Advertisement

Archived

This topic is now archived and is closed to further replies.

Automatic portal generation - HELP!!

This topic is 5028 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi I''ve got my nice BSP compiler working with XML (good stuff that) adn it works just fine, but I have a problem when I generate portals using the method outlined in that guy''s article on this site. For some reason, my portals get generated all over the walls (which I don''t want), and not in the "doorways" between rooms/bspnodes (which is the only place I want them!!!) Why oh why oh why? Or alternatively, is his algo flawed, or does someone have a better way of doing it? Thanks Chris

Share this post


Link to post
Share on other sites
Advertisement
I''m implenting the same thing at the moment, so I can share my results in a few days if you will be still interested...

Share this post


Link to post
Share on other sites
I thought I could redo the algo using an edge table to determine what''s a hole and what''s not (holes are what get capped with portals)

Basically, I build a list of directional edges (eg v23 -> v24)
and then find from that the edges that are only used in one direction.

(this is because two triangles sharing an edge will use it in different directions, this should find all the edges of holes.)

I could then take any 2 "edge" edges that share a common vertex and construct a plane from them.

Then I determine the set of edges that lie on the plane, and construct the portal poly from them.

The portal''s destination can be determined by the following method:

1. determine the normal and centroid of the polygon.
2. add some proportion of the normal to the centroid and determine which node the resulting point is in.
3. subtract the same proportion from the centroid to determine the node on the other side.

The destination is [obviously] the node that is not equal to the node containing the portal.

Once a portal is generated, its edges get added to the list so the ''hole'' in the edgelist is ''capped''.

Is this better/worse/what/comments?

Chris

Share this post


Link to post
Share on other sites
your design can be streamlined by using the existing BSP tree to create your portals. basically, for every node in your tree, you create one portal using that node''s plane. you then pass this portal through the that node''s front list, clipping it like any other polygon. if part of a portal ends up in negative space (in a wall) it gets discarded. you know you''ve finished when the final clipped portal ends up in a leaf. actually, through the clipping, the initial portal could end up with several "possible" final portals, each ending up in a leaf. however, a portal is only valid if it exists between two leafs. this is your problem. you have portals that, say lie on a wall. what you would do is, pass the eacfh portal in this list of portals (created from clipping an initial portal) down the node''s back list, processing it just the same as the initial.

in our engine, our portal class, which is derived off of our polygon class, has a member: long leafs[2] this stores the indices into our leaf array of the leaves this portal exists between. when we''re done clipping a portal, if there''s not 2 indices in there, we throw the portal away. we''ve actually adapted this method somewhat to make special portals on the exterior of a building, say an outside window or door, to enable us to distinguish them from interior portals. the exterior portals allow proper visibility information when viewing the outside world (processed with Octrees) from the inside world (BSP based). we''ve got a good design, and hope to make a great BSP-Octree indoor-outdoor system.

Share this post


Link to post
Share on other sites

  • Advertisement