It is currently Mon Jun 26, 2017 12:27 am

All times are UTC - 5 hours




 Page 1 of 1 [ 7 posts ] 
Author Message
 Post subject:
PostPosted: Wed Mar 07, 2007 6:02 pm 
Site Admin

Joined: Sun Feb 11, 2007 8:59 am
Posts: 1094
Location: Ontario Canada
In this video I show you how to modify the scene graph structure so that you can easily make things invisible/visible by changing one parameter.


Offline
 Profile  
 
 Post subject: Extended invisibility
PostPosted: Mon Nov 17, 2008 6:40 am 

Joined: Wed Aug 06, 2008 7:53 pm
Posts: 182
Location: Russia
Hi Marek.
My question is: why visibility flag is tested only inside the NodeTransformation::Render() ? IMHO, this reduces the game world developer's DOF. For example, assume we have the following hierarchy:
   [+] "NodeTransformRoot"
      [+] NodeGeometry_1
      [+] NodeGeometry_2

Right now we have only the option to hide/show the whole group: NodeGeometry_1 & NodeGeometry_2. But if one wants to change the visibility of NodeGeometry_1 independently of NodeGeometry_2 she has to needlessly complicate the hierarchy up to:
   [+] "NodeTransformRoot"
      [+] "NodeTransform_1"
         [+] NodeGeometry_1
      [+] "NodeTransform_2"
         [+] NodeGeometry_2


Hereof my suggestion is that we should add the test of Visibility inside NodeGeometry::Render() as well, to be able to manipulate the visibility of geometrical objects individually (not bulking up the graph).

What do you think?



_________________
«Computer scientists deal with algorithms that you may call practical in theory but unpractical in practice.» © Timothy Gowers
Offline
 Profile  
 
 Post subject:
PostPosted: Mon Nov 17, 2008 8:29 am 
Site Admin

Joined: Sun Feb 11, 2007 8:59 am
Posts: 1094
Location: Ontario Canada
Very good point BugHunter.

I came across this issue when I was working with my game engine for a project. I changed my code to correct this problem, but I guess I never made a VMK to show the rest of the people online :)


Offline
 Profile  
 
 Post subject:
PostPosted: Mon Nov 17, 2008 9:27 am 

Joined: Sat Jun 23, 2007 7:56 pm
Posts: 145
I have the visibility variable as a member of the base Node class.

That way, any node that inherits from it can decide when its visible or not.

So in a quad tree, the transform nodes' visibility flag can be used to decide if it should be processed or not.
For my frustrum culling code, the geometry nodes' visibility flag is used to signal if it was culled or not.

This variable in my engine is called m_ignore.
I this its more versatile that way.


Offline
 Profile  
 
 Post subject: m_visible / m_ignore (m_skip) clash?
PostPosted: Mon Nov 17, 2008 11:22 am 

Joined: Wed Aug 06, 2008 7:53 pm
Posts: 182
Location: Russia
Good to know that so many people have collinear views. :)

2 codeslasher
In the original VMK26 m_bVisible is declared also right in Node class, but is used only in NodeTransform (that worried me).
But stop, isn't your Node::m_ignore flag overused? I mean, don't you have a clash when you want to make an object invisible as a result of game logic versus visibility clipping algorithms? I would keep two independent flags:
if ( GetVisibleFlag() && ! GetIgnoreFlag() ) {
    ... draw this node ...
}


Or...?


Last edited by BugHunter on Mon Nov 17, 2008 1:15 pm, edited 1 time in total.


_________________
«Computer scientists deal with algorithms that you may call practical in theory but unpractical in practice.» © Timothy Gowers
Offline
 Profile  
 
 Post subject:
PostPosted: Mon Nov 17, 2008 12:19 pm 

Joined: Sat Jun 23, 2007 7:56 pm
Posts: 145
The flag basically means - "For what you are doing, if am set to TRUE, don't bother processing me and just continue on to the next task/node"

So it works well, for rendering if I set it manually to TRUE, its not rendered and hence invisible.
For collisions, if TRUE, the node is not processed, (same as it being invisible. Imagine if someone walks into an invisble wall and being stopped, they would wonder why.)

And so on.

(Carrying on from my example of an invisible wall, I think if you wanted to model - Force fields and invisible barriers, you'd need some visual representation anyway. So using lightly textured object that has transparency in its texture for that would mean this flag can be left as FALSE and players would know why they can't progress any further.)

But it also can't hurt to split it, just means you have to make 2 checks all the time. (could get out of synch)


Offline
 Profile  
 
 Post subject: not quite clear
PostPosted: Mon Nov 17, 2008 1:15 pm 

Joined: Wed Aug 06, 2008 7:53 pm
Posts: 182
Location: Russia
1. I've added "!" in front of GetIgnoreFlag() (above), my fault. It's obvious that m_ingnore should use "inverse logic".

2. As I understand the culling algo, it turns m_ignore on (when the object left the visible volume) and off, appropriately. Well, consider following scenario. Your game-logic makes an object invisible (say a dead monster must disappear) => m_ignore = true. Then a player makes a full 360˚ turn, as a result, culling algo set m_ingnore = true, then back m_ignore = false, overriding game-logic decision. Or maybe I still don't know/understand something. :?

3. I's easy to avoid double check if we use bit-flags (if we worry about performance).



_________________
«Computer scientists deal with algorithms that you may call practical in theory but unpractical in practice.» © Timothy Gowers
Offline
 Profile  
 
Display posts from previous:  Sort by  
 Page 1 of 1 [ 7 posts ] 

All times are UTC - 5 hours


Who is online

Users browsing this forum: No registered users and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Jump to:  

cron