Hide Entity from 1 of 2 Cameras
Blitz3D Forums/Blitz3D Programming/Hide Entity from 1 of 2 Cameras
| ||
| Does anyone know if there is a way to hide an entity from 1 camera only? I have one camera (SkyCam) which displays the game field, also there is another camera (RadarCam) which gives an overhead view of the entire terrain. What I want to do is have a DOT (Entity) above the actors to show their position on the RadarCam, but I don’t want this DOT visible to the SkyCam. Can this DOT be hidden from the SkyCam only? |
| ||
| Only perhaps, to render twice, first hiding the dots and camera two, then again showing camera two, hiding camera one but showing the dots. Although this would be significantly slower. |
| ||
| I suggest rendering the radarcam view and then rendering the dots on top of it by putting a camera somewhere far away in the world, like at 65536,65536,65536 and setting that camera to clear the zbuffer but not the color buffer, and placing it's viewport right over the radar cam view. Then you just offset the dots from the players by 65536,65536,65536 and that will place them under the radar dot camera so it can see them, but everyhting else will be really far away. I have talked to Mark about this sort of thing before, and he changed how hideentity and showentity work so that eventually he will be able to implement multiple "worlds" and each entity can be part of a specific world. That way you could do this without having to render the dots off in some far corner of the world and it may render faster as well since there won't be a lot of extra geometry which is outside the clipping planes. I'm not sure if that stuff that gets clipped slows the rendering down in any way or not. I don't beleive it does though. So the main benefit will just be a better system for multi-pass rendering. |
| ||
| Swift, Batman, I handle this in my GUI which has multiple 3D windows. Resizable at that. Any way I render twice or more and manage the entities (hidden/not hidden) by setting up a "type" system that manages all entites for each cammera. my experience has been that newer cards handle the render faster then messing around with stuff. Also, as I understand it the lastest Blitz3D update allows for hide/show to be very fast. My experience with this in my GUI showed that this was the fastest way I could do it. In fact doing it this way allows me to have multiple 3D worlds (as you describe) all using the same coordinates and 3D space. Here is a demo of what I'm talking about: http://members.getgoin.net/~vidiot/B_Windows_Beta_17.zip good luck;) L8r, |
| ||
| I do reccomend this approach, though so far I have found it too much of a pain to bother with myself. Also, this approach isn't the sort of thing a third party engine can force a user to comply with, so libraries which are designed to work with any program can't use this sort of system. That will all change when mark implements the multiple worlds thing though. |
| ||
| Swift, Also, this approach isn't the sort of thing a third party engine can force a user to comply with, so libraries which are designed to work with any program can't use this sort of system Actually, this is not a problem in the demo I posted since it uses a window based approach each window is processed using the same 3D space one at a time. So even the Backbuffer() is open for third party libraries. In addition to this management of entities allows for normal use of said libraries. I would agree that it's a pain to code something like this but the efforts are rewarding as they can allow future cross-platform capabilities when Bmax arrives. L8r, |
| ||
| No I mean in order to be able to hide all the entities, you have to store them in a list. So any library like a hud system, that wants to use this sort of method would have to force the user to store all the entities the way the writer of the library wants. And if you're using several different libraries by several different people then this is gonna get messy fast. |
| ||
| Swift, In most cases it's still posible. As long as you know the handle/arrary handle/type handle. I use a function (b_add_window_entity(window_handle,entity) ) which registers the entity to a window. For example I have had two different particle systems working in two different windows with little modification to the libraries. The GUI hides all entities not registered with the system so roge entities are not displayed. So I can "modify" libraries to work with in that window. Only entities that will be rendered are of concern. This make it easier to include lidraries. Anyway.. Batman is probably going what :) L8r, |
| ||
| "The GUI hides all entities not registered with the system so roge entities are not displayed." Um... how do you hide entities not registered with the system? Blitz doesn't have a command to hide all entities in the world. |
| ||
| I can't see this multiple world thing being much of a stretch from where we are now. You can pretty much achieve the same thing using pivots, though I wonder how you envisage the rendering improvements working. I suppose you mean cameras will belong to worlds and you only need one renderworld to render all camera views for each world. Would that be any more efficient behind the scenes though, than hiding pivots and doing multiple renders as you can at the moment? I suppose the multiple world thing though will mean you can iterate through every entity in every world, which is not something you can do at the moment without imposing the restriction that you have world pivot(s) and parent your entities to those. Just another type of linked list. It would be nice then if the system returned more entity information so you actually know what you have got. I guess you could use the entityname string to store this information as it stands now though, but an entity type field might be useful (pivot,mesh,terrain,plane etc). |
| ||
| Thanks for the Feedback... I will give some of this a try... Thanks |
   |