Hi !
Featured games (85)
games approved by the League of Dukes
Games in Showcase (616)
Games in Android Showcase (173)
games submitted by our members
Games in WIP (659)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Portals and objects  (Read 1637 times)
0 Members and 1 Guest are viewing this topic.
Offline Orangy Tang

JGO Kernel

Medals: 57
Projects: 11

Monkey for a head

« Posted 2002-11-26 15:57:50 »

I've been thinking about portal based space division and rendering recently (nice collumn over at if anyone is wondering what I mean by portals) but while most of it makes sense and sounds like a good system, I've become stuck on an important point: moving objects.

Static level geometry is ok, lets assume that we've nicely carved up our world into convex sectors and portals storing their connectivity. Portals join two sectors via a plane/portal geometry. Theres nothing to stop T junctions between three sectors though, and these are likely to be pretty common.

So where do we insert our dynamic objects? If its totally within a sector then it'll be stored in an ArrayList or similar expandable data structure, but what to do when it overlaps two sectors? Store in a list in the portal? But then what to do if the object overlaps a T junction of three or more sectors (and therefore more than one sector).

Ideally I'd like to avoid storing multiple references to the same object, since this makes it easier in many areas (mainly for removing/adding when the object moves).

Anyone any ideas?

[ - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline EgonOlsen
« Reply #1 - Posted 2002-11-26 18:12:13 »

In my engine, i'm not storing references to objects in the sector but references (in fact not even that but simple sector-numbers...anyway...) to the sectors an objects covers in the object itself.
I'm using three kinds of objects:

1 - Objects without any sector binding...they will always be rendered/processed. This could be usefull for short-living, simple objects like particles, gunshots etc.

2 - Static objects that belong to a specific sector and that don't move at problem here...

3 - Moving objects with an automated sector-detection. I detect all sectors such an object covers and if it's only one, i simply process them like they were static. If it covers more than one sector, i assume that it is visible if at least one of the sectors it covers is visible.

I'm not doing pixel-perfect clipping on the portals but polygon wise culling in a way that i assume a polygon of a multi-sectored object as being visible if it is visible through at least on portal into a sector it covers.

Offline Orangy Tang

JGO Kernel

Medals: 57
Projects: 11

Monkey for a head

« Reply #2 - Posted 2002-11-26 20:21:18 »

So how do you get from a Sector object to all of the dynamic objects contained within it? This is pretty important for fast collision detection (amongst other things) so some sort of global search isnt really practical (and would defeat the point somewhat).

[ - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline EgonOlsen
« Reply #3 - Posted 2002-11-27 13:48:16 »

Quote some sort of global search isnt really practical (and would defeat the point somewhat).
In theory: yes, you are right. In practice: It's a very cheap operation. What i'm actually doing is this: I detect which sectors are visible (or covered by an object for collision detection in that case) and store them in a list. Then i'm iterating through the objects that are attached to my world-object (i'm doing this anyway) and simply ask them, if they are in one of the relevant sectors. If they are, they need further processing (rendering, collision detection...). This is really a very cheap operation and nothing compared to the more advanced operations that are happening later in the pipeline (per polygon and even per pixel because it's a software renderer).
What i'm not doing is to collect all objects that belong to a specific sector. I simply don't need this information. My portals are an option, not a must. You can build a level without using a single portal (you don't even have to care about the fact that they are an can just ignore them completely). This will be slower of course, but it's possible.

Pages: [1]
  ignore  |  Print  
You cannot reply to this message, because it is very, very old.

Coldstream24 (16 views)
2015-09-03 00:41:28

Andrew_3ds (27 views)
2015-09-01 19:08:10

afikri (18 views)
2015-08-31 09:30:22

afikri (25 views)
2015-08-31 09:30:07

afikri (13 views)
2015-08-31 09:27:24

afikri (16 views)
2015-08-31 09:26:40

Roquen (30 views)
2015-08-29 11:30:54

GamerC4 (36 views)
2015-08-22 20:38:50

GamerC4 (33 views)
2015-08-22 20:37:18

GamerC4 (40 views)
2015-08-22 20:37:01
HotSpot Options
by Roquen
2015-08-29 11:33:11

Rendering resources
by Roquen
2015-08-17 12:42:29

Rendering resources
by Roquen
2015-08-17 09:36:56

Rendering resources
by Roquen
2015-08-13 07:40:51

Networking Resources
by Roquen
2015-08-13 07:40:43

List of Learning Resources
by gouessej
2015-07-09 11:29:36

How Do I Expand My Game?
by bashfrog
2015-06-14 11:34:43

List of Learning Resources
by PocketCrafter7
2015-05-31 05:37:30 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!