Jump to content
The Dark Mod Forums

C777 Application


Recommended Posts

Oh! Didn't think about that. :wacko: You mean, you have to switch control directions according to the current camera orientation as well. Otherwise it will be totally confusing for the player. He looks through a camera right in front of him and walks to the left, but the next camera is on the opposite position, so the player must now walk to the left in order to continou in the same direction as before. Do you mean stuff like this?

Gerhard

Link to post
Share on other sites
  • Replies 75
  • Created
  • Last Reply

Top Posters In This Topic

Usually in such schemes, controls don't change to match the current camera orientation until all buttons are released. (so if you hold down a button you would continue to walk in one direction, even if it's different from what the current camera would dictate)

Link to post
Share on other sites

heres what i have in mind..

 

http://pg.photos.yahoo.com/ph/hamadalomani...omani/my_photos

 

the 3 cameras target are the player, the 1st camera follows player(the camera dont just view what infront of it, it follows the player around, only if you guys want to add more option :P) until the player reachs the 1st trigger the 1st camera will be turned off and the 2nd camera will start and so on, when the player reachs the 3rd trigger the 3rd camera will turn off, this will switch to 3rd person, when the player reachs 3rd trigger the 3rd camera will follow the player and so on

Link to post
Share on other sites

The D3 documentation also says that touch triggers are expensive, and having a lot of them active might be a drain on performance.

 

I think you could do it with the location system though, just have a quick check each frame to see what location area the player is in (gameLocal::GetLocationForPoint( <player origin> ) and then use the camera position for that given location. That way you can effectively use visportals and location separators (which are not that expensive indoors) as triggers, without having a lot of actual trigger_touch entities active.

Link to post
Share on other sites

How big are these locations? In Doom 3 it usually was several rooms, but that was mainly IMO because it fit the environment. If you can have one location per room, then it should be easy. Just link a camera entity to it's location name. If you need multiple cameras per room, then you could either make smaller locationinfos or the camera might determine it by itself, by testing wether the player is visible in it's view.

Gerhard

Link to post
Share on other sites

You could do one per area instead of one per location, but areas are defined by visportals. A concave-shaped room may be split into many areas if visportals are in place.

 

Making each place you want a camera a location might get tedious, but I don't know of a better way to group several visportal areas together in the editor.

 

You could try it with trigger_multiples at all the room entrances and exits too, although you'd have to see if performance went down with a lot of triggers being tested each frame.

Link to post
Share on other sites

If you design such a game, it's cumbersome anyway, to place the cameras, and requires a lot of testing. But I think performancewise assigning it to locations is the easiest one to code. Triggers will also have to be evaluated each frame (or at least whenever the player moved).

Gerhard

Link to post
Share on other sites

I just checked this with the location info. It is tied to visportals, so we can not really use this. I had another idea though. I might be able to create a similar class like the lights, because essentially a light is pretty similar to what you need. It has a location, and a box attached, but of course the new class shouldn't be light, because this would be unneccessary overhead. Reusing the light class might still be a benefit, because it would allow you to work with this class in the editor to define the boundary of the area where the camera should work.

Gerhard

Link to post
Share on other sites
I just checked this with the location info. It is tied to visportals, so we can not really use this.

 

Yeah it's tied to visportals, why does that mean we can't use it? You define locations by putting info_location_separators at the visportals you want to limit the extent of your location, and everything within that is in the location, and you could define the camera setup on the info_location entity that sits inside that location. Seems like an easy way for mappers to define what areas they want covered by what cameras.

Link to post
Share on other sites

But visportals only define the areas in terms of a room. In this case you most likely need at least two cameras for any normal room, to make sure the player is visible at all times. I think if you use visportals for that purpose, you will get a big performance drain. I think that having a specific entity, that defines a box and a location and the orientation of the camera would be much easier to use, and is probably faster, then having to create all this visportals for a decently sized level. In most such games you have at least two cameras in most rooms, which would mean already two visportals per room.

Gerhard

Link to post
Share on other sites

Hmm, I didn't know they'd need two cameras per room. In that case yeah, you might have to put in some otherwise-unnecessary visportals. Indoors, I don't think that will be a big performance drain. The performance drain seems to come when the visportal area tree branches out to some huge number of portals at one point. I woudn't think adding another non-branching portal to a room would hurt the performance that much (i.e., the portal would only connect the first half of the room and the second half of the room, and not connect to 50 other portals where the performance goes to crap).

Link to post
Share on other sites

Sort've. When you put in visportals, D3 compiles all that into a tree, saying "this area can see this next area, this next area can see three other areas", etc. I'm saying that if you have to add portals to facilitate breaking up the room into multiple camera angles, you're usually just adding another connected point along a single branch, rather than creating another branch on the tree. The renderer only cares about the parts of the tree currently connected to you, so while it may take longer for the map to compile with more points on each branch, it shouldn't have a significant impact on ingame performance.

 

If you have small rooms like that in tight quarters, you don't have many "branches" in the first place, since you can only see into a few rooms from any given point. I could be wrong, but I think it would be okay. Also, for rooms that small, it looks like you only need one camera per room anyway, so you wouldn't have to add extra visportals?

 

Btw, those are some nice looking screenshots :).

Link to post
Share on other sites

If all the rooms are that small, one visportal might suffice. But visportals are no entities, they are part of the world geometry. So how do you know when a visportal is crossed? And you need an entity, that stores the info of the camera and angle.

Gerhard

Link to post
Share on other sites

You know the visportal is crossed by calling gameRenderWorld->PointInArea( player->GetOrigin() ) :)

 

In other words, it's not a trigger that's crossed, but the renderer is always keeping track of what area the player is in (I think it internally updates once per frame, but I'm not sure), and this is a very inexpensive call to make once per frame in the "camera determination" code. That returns a number, which is the index of the area. Then all you have to do is make an array with pointers back to the appropriate camera data object, so if you read off the entry at the index corresponding to the area you're in, it points back to the right camera.

 

(I.e., instead of something that's triggered, you would figure out what camera to use every frame, but it would be an inexpensive function call and array lookup. You're going to need to see if you need to switch to the first person cam every frame anyway, if the "aim button" is held down or whatever)

 

To associate camera location with area number, you would put your camera data info on an extra entity anywhere within the area. You could use a location object to store the data for multiple portal areas in one place, but since the areas shown are so small, it might be quite a pain to define all those areas as an extra location (which requires putting info_location_separators at all the portals connecting to other locations).

 

Instead, you could make your own data object that records what area it's in when it spawns, and then writes that to an array that's indexed by area number and points back to the camera data object.

 

I do exactly this for soundprop in case people want to override location data in a specific area within that location. The same code could be used for associated a camera with an area. You could expand it to also use the location system (which is accessed in a very similar way) later if you found that you had a lot of portal areas that should use the same camera and placing camera data entities in each area was getting tiresome.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...