Jump to content
The Dark Mod Forums

Apples and Peaches: Obsttorte's Mapping and Scripting Thread


Obsttorte

Recommended Posts

Could we use this to peer through door keyholes?

I thought about that possibility, too.

@Biker: Once I got my internet working correctly so I can upload larger files I'll do so.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

Can ou upload a test map please..?

Here ya go

camera.pk4.txt

  • Like 2

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

How does this work in combination with visportals? Will the stuff you see through the camera be under the same rules regarding visportals as everything else? Say, if you have a fake window with a projected image of a room which is placed where the player can not see it, will it still get rendered from the player's position? Or maybe that doesn't matter if it is an enclosed room that gets projected.

I have tested it and it works as expected. So no problems if the camera is not inside a visable visleaf.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

I presume what happens is that the camera acts like a secondary PVS and vis calculations are done from it to the visportals within

the camera's PVS.

 

My theory is that the new portal sky code can possibly act as a better LOD system in some cases because the longer the view the larger

the evaluation area for light and visibility calcs. When you use the Portal Sky to represent the far draw distance, it reduces the traversal

distance at the expense of having to run the calcs again from another origin. If my presumption is correct, the longer the traversal distance

the more difficult the evaluation math so breaking up the scene traversal this way might be even lighter than LOD alone. The problem being

that you would need to have AI pathing that seemlessly transitions out of the portal sky into real space and the lighting transitions from real

space to portal sky space. Still, something to ponder or test...

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

I presume what happens is that the camera acts like a secondary PVS and vis calculations are done from it to the visportals within

the camera's PVS.

 

My theory is that the new portal sky code can possibly act as a better LOD system in some cases because the longer the view the larger

the evaluation area for light and visibility calcs. When you use the Portal Sky to represent the far draw distance, it reduces the traversal

distance at the expense of having to run the calcs again from another origin. If my presumption is correct, the longer the traversal distance

the more difficult the evaluation math so breaking up the scene traversal this way might be even lighter than LOD alone. The problem being

that you would need to have AI pathing that seemlessly transitions out of the portal sky into real space and the lighting transitions from real

space to portal sky space. Still, something to ponder or test...

I think the camera rendering and portal sky are two diferent parts of the code, thus not belonging together.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

An observation regarding the camera. You can not have two different screens showing two different views at the same time.

 

 

 

http://youtu.be/gojaewa6SNU

Even if it's not possible with multiple cameras, I can see this being really useful for missions.

 

EDIT like a secret watching hole in a wall or something similar.

Edited by Paralytik

"My milkshake bringeth all ye gentlefolk to the yard. Verily 'tis better than thine, I would teach thee, but I must levy a fee."

"When Kleiner showed me the sky-line of New York I told him that man is like the coral insect—designed to build vast, beautiful, mineral things for the moon to delight in after he is dead."

https://soundcloud.com/paralytik

 

Link to comment
Share on other sites

Is the camera interface a portal or a picture?

I mean, is the surface just an IMAGE of what lies beyond (i.e a 2 tris flat plane with a updating image on it), or is it a sort doorway portal, so that all the tris beyond are rendered?

 

If it was an image, then this could be used for peer-inside windows that have no performance impact.... Or a func portal, that when the portal is closed, shows roughly what lies beyond.

Clipper

-The mapper's best friend.

Link to comment
Share on other sites

Another thing that came into my mind regarding the camera is the use of func_portals together with the spawnarg "portal_dist", which allows to force a portal to be closed if the player is farther away then the distance set there to save performance.

 

I don't know whether the code is always taking the player into account for distance checks, or if it takes the entities whose view s currently rendered (for example a camera). In the first case, it could be that if the observation screen providing the view of the camera is too far away from a vp in the fov of the camera using such a feature, the vp is closed and therefore the screen would provide a screwed image. I will have to test that.

 

In addition mappers should consder the possible performance impact coming from that method. As already said you can set the resolution in the material file. Nevertheless it is an additional rendering pass which will cost extra performance so it may be a good idea to follow the following two basic rules:

  1. The scene which is visible for the camera and therefore rendered on the screen should be performing good. A high detailed area which already causes framedrops if the player is in there may be performing even worse.
  2. The observation screen should be placed in a way so that the room it is in is not overdetailed or -lightened and that no visportal is in the players fov when he is looking at the screen. A seperate "observation room" may do the trick here.

These are just things that may help avoiding performance issues. However, as always it depends on the respective FM this may get used in and is a matter of testing. Maybe you don't have to keep to that "restrictions".

 

Regarding the keyhole:

 

As said this is more a proof of concept. What needs to be done is:

  • Make the keyhole unfrobable so the player does not get doesn't of gui overlays influencing each other when pressing the frob key several times (you could see that effect in the video)
  • make sure that the keyhole view is only rendered when the player actually uses this feature
  • check whether it is possible to disable the rendering for the player while he is in the peer-mode (nice name, I may stick to that :) ). this is optional as the performance impact should be the same as if the player opens the door ;)
  • make sure that the player get's "thrown out" of the peer-mode if he receives damage
  • possibly disable peering if the player get's chased by guards, so he does not accidently ends up in that mode when trying to flee through a door
  • add an zoom-in and zoom-out effect like in Thi4f
  • anything else that may come into your mind

Other possible uses are

  • scouting orbs like in Thief 2 as already mentioned by someone else
  • a device that allows the player to "hack" into a camera to use it for scouting, or even a mechanical guard/steambot like they were present in Thief 2 or in Sotha's last FM (at least I think they are bots)

@Sotha:

 

There is a func_cameraview attached to the door on the side which faces towards the room with the builder in it, "looking" away from the door (by default it looks into the positive x direction, you can change that by rotating the entity).

 

The image in front of the door is a func_static using the above posted material with a keyhole image blend filtered above it. The same material is used for the gui overlay which is created once the player frobs it. This is done via an frob action script, which also disables player movement and view turning and waits for the player to press the attack key (left-mouse button).

 

The func_static is only a temporarely solution. I'll try to set up a custom door entity which does not use that and deals with as much as the above mentioned issues as possible.

 

And yes, this method could also be used instead of transparent windows. The rendered area will stay the same in most cases, but the rendering resolution could be much lower. Together with some blurring effects (heat haze, dirt decals etc...) players may not even notice the lower res.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

Since you mentioned some kind of conflict that prevents two active screens simultaneously, it would be a good idea to test how (if at all) it works with mirrors (including reflective water volumes and puddles).

 

Also related, there's a fun bug/side effect of mirrors: since glare coronas and other "billboard"-type particles always face the player, their reflection might turn out facing the player sideways (might need to take a screenshot to support my poor wording). I'd bet it applies to any additional PoV's as well.

Link to comment
Share on other sites

... their reflection might turn out facing the player sideways (might need to take a screenshot to support my poor wording)

I understand what you are meaning ;)

 

I will test that when I find the time.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

  • 3 weeks later...

I want to let the player turn his view a bit when peeking through the keyhole. For this purpose I want to use mouse gesture detection. The problem I am having now is as follows. If the player did not move his mouse, the getMouseGesture() function should return 0, but it doesn't. It returns 1 all the time.

 

Is this a known bug?

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

Since I like this thread and the new concept of cameras in it so much I've gone and made a model (.ase) for a camera, plus a test map with all the setup - sound, lights, switches etc. Features:

- Camera lens can be recoloured freely via the _color spawnarg

- 2 versions: with or without lamp

- Has an 'on' and 'off' skin

- Has sounds

- Live feed into a purpose built surveillance screen

- Linked up to an alarm

- Lights/sounds can be turned on/off with the switch on the control board

- Responds to water arrows

 

Known bugs:

- I haven't found a way to stop the func_securitycamera entity itself, things like remove or kill will also remove the func_static camera model.

- The camera is hypersensitive and detects the player in complete darkness.

- The only way to avoid detection is to hide behind an object.

- The camera resets its sweep from wherever it's stopped at after it's seen the player.

post-3526-0-71133700-1408471670_thumb.jpg

cameramodel.pk4.txt

  • Like 2
Link to comment
Share on other sites

There is a scandist argument which defines how far the camera can see. If you set it to zero, it will not detect you. Regarding the see in darkness I will have to take a look.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

I want to let the player turn his view a bit when peeking through the keyhole. For this purpose I want to use mouse gesture detection. The problem I am having now is as follows. If the player did not move his mouse, the getMouseGesture() function should return 0, but it doesn't. It returns 1 all the time.

 

Is this a known bug?

 

Would it be possible to detect a change in the player view angles? I detect movement of the player by recording its old position and comparing it with the current. Crude, but works :)

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Yeah that's possible. In my case the player would not notice it, because he sees the keyhole view, not the view of his "avatar". However, if someone wants to do this with the player still seeing through his won eyes, this is noticeable if you don't want the player to be able to turn. For this case the mouse gesture functions were implemented me thinks. In the current state, they are completely useless (as you could always fallback to the crude approach).

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

Yeah that's possible. In my case the player would not notice it, because he sees the keyhole view, not the view of his "avatar". However, if someone wants to do this with the player still seeing through his won eyes, this is noticeable if you don't want the player to be able to turn. For this case the mouse gesture functions were implemented me thinks. In the current state, they are completely useless (as you could always fallback to the crude approach).

 

Uh, I'm not sure getMouseGesture() does what you want:

 

const idEventDef EV_Player_GetMouseGesture( "getMouseGesture", EventArgs(), 'd',

"Returns the results of the last mouse gesture in enum form.\n" \

"(see the definition for MOUSEDIR_* for which numbers correspond to which directions)");

 

How did you try to use it?

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

I know how to use it. The problem is, that there is also a MOUSEDIR_NONE = 0, for the case that the mouse movement could not be evaluated clearly (for example because the player didn't move it). But the code does not use this. If such a situation occours, it just returns one, which equals to a mouse movement towards the left.

 

If you take a look at the scriptobject for the swordshord, you will see that the attack function actually takes that into account, while the block function takes the possibility into account, that MOUSEDIR_NONE get's returned.

 

In a situation like attacking/blocking it does not make a difference, because you want to perform any action anyway. Doing nothing isn't an option.

 

In my case, doing nothing IS an option. (capital letters for stressing, not for yelling :) )

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

Well, sounds like a bugtracker enty is in order then :) Sorry for doubting you - was just asking for clarity.

 

The code in StartMouseGesture() does not initialize the variable result, this piece of code is likely just missing:

 

m_MouseGesture.result = MOUSEDIR_NONE;

 

The code has this comment, tho:

 

// NOTE: Do not clear the last result as we may use it again if we can't decide

 

If the code cannot decide on a mouse gesture, chould return NONE instead of the last one?

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

I've actually already opened a thread for this to ask whether I can change that: http://forums.thedarkmod.com/topic/16482-broken-mouse-gesture-test/

 

Nobody replied, so nobody seem to care. So if I change it, it will not get implemented anyway and I can spare that time.

 

The problem is the marked code:

 

void idPlayer::UpdateMouseGesture( void )
{
float mag(0.0f);
EMouseDir CurrentDir;
m_MouseGesture.motion.x += usercmd.mx - m_MouseGesture.StartPos.x;
m_MouseGesture.motion.y += usercmd.my - m_MouseGesture.StartPos.y;
if( m_MouseGesture.bInverted )
 m_MouseGesture.motion = -m_MouseGesture.motion;
EMouseTest test = m_MouseGesture.test;
idVec2 motion = m_MouseGesture.motion;
// Get the current dominant direction and magnitude
// NOTE: Apparently y is positive if we go down, not up?
if( test == MOUSETEST_UPDOWN )
{
 if( motion.y < 0 )
  CurrentDir = MOUSEDIR_UP;
 else
  CurrentDir = MOUSEDIR_DOWN;
 mag = idMath::Fabs( motion.y );
}
else if ( test == MOUSETEST_LEFTRIGHT )
{
 if( motion.x > 0 )
  CurrentDir = MOUSEDIR_RIGHT;
 else
  CurrentDir = MOUSEDIR_LEFT;
 mag = idMath::Fabs( motion.x );
}
else if( test == MOUSETEST_4DIR )
{
 // up/down motion dominant
 if( idMath::Fabs(motion.y) > idMath::Fabs(motion.x) )
 {
  if( motion.y < 0 )
   CurrentDir = MOUSEDIR_UP;
  else
   CurrentDir = MOUSEDIR_DOWN;
  mag = idMath::Fabs( motion.y );  
 }
 // side/side dominant (default left for zero input)
 else
 {
  if( motion.x > 0 )
   CurrentDir = MOUSEDIR_RIGHT;
  else
   CurrentDir = MOUSEDIR_LEFT;
  mag = idMath::Fabs( motion.x );
 }
}
else
{
 // Test along 8 directions (NOT TESTED!)
 // Step 1, resolve onto diagonal basis
 idVec2 DiagVec;
 // upper right
 DiagVec.x = motion * idMath::SQRT_1OVER2 * idVec2(1.0f,1.0f);
 // lower right
 DiagVec.y = motion * idMath::SQRT_1OVER2 * idVec2(1.0f,-1.0f);
 // figure out which is dominant
 idList<float> dirs;
 dirs.Append(idMath::Fabs(motion.y));
 dirs.Append(idMath::Fabs(motion.x));
 dirs.Append(idMath::Fabs(DiagVec.x));
 dirs.Append(idMath::Fabs(DiagVec.y));
/******************************************************************/
 mag = 0.0f;
 int MaxAxis = 1; // default to left if we have zero  motion <---------------- especially this
 for( int i=0; i < 4; i++ )
 {
  if( dirs[i] > mag )
  {
   mag = dirs[i];
   MaxAxis = i;
  }
 }
 // up/down
 if( MaxAxis == 0 )
 {
  if( motion.y < 0 )
   CurrentDir = MOUSEDIR_UP;
  else
   CurrentDir = MOUSEDIR_DOWN;
 }
 // left/right
 else if( MaxAxis == 1)
 {
  if( motion.x > 0 )
   CurrentDir = MOUSEDIR_RIGHT;
  else
   CurrentDir = MOUSEDIR_LEFT;
 }
 // lower right/upper left
 else if( MaxAxis == 2)
 {
  if( DiagVec.x < 0 )
   CurrentDir = MOUSEDIR_UP_LEFT;
  else
   CurrentDir = MOUSEDIR_DOWN_RIGHT;
 }
 // upper right/lower left
 else
 {
  if( DiagVec.y < 0 )
   CurrentDir = MOUSEDIR_DOWN_LEFT;
  else
   CurrentDir = MOUSEDIR_UP_RIGHT;
 }
}
/******************************************************************/
// If above threshold, decision timer ran out, or button released, we're done
if( mag > m_MouseGesture.thresh
 || (m_MouseGesture.DecideTime >= 0 && (gameLocal.time - m_MouseGesture.started) > m_MouseGesture.DecideTime)
 || !common->ButtonState(m_MouseGesture.key) )
{
 m_MouseGesture.result = CurrentDir;
 StopMouseGesture();
}
}

The changes are minor, but unless someone wants this to be changed ...

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
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.


  • Recent Status Updates

    • Ansome

      Finally got my PC back from the shop after my SSD got corrupted a week ago and damaged my motherboard. Scary stuff, but thank goodness it happened right after two months of FM development instead of wiping all my work before I could release it. New SSD, repaired Motherboard and BIOS, and we're ready to start working on my second FM with some added version control in the cloud just to be safe!
      · 0 replies
    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
×
×
  • Create New...