Camera Modifications (Roja this is for you)

[emajekral]

UPDATE: Patch and Binary removed pending 1.3.1 update. Once the new source and client are released and I make my stuff work with them I may replace them.

 

Windows version can compiled with Dev-C++5. See how to compile the client by clicking the link in the next paragraph for a tutorial. (Post to that thread if the tutorial is broken)

 

I would have had it up sooner but I had a wrestling match with VC6, gave up and had another with Dev-C++5. I won the latter. Victory speech here After that I test compiled it and discovered I had nearly destroyed the shadows and lighting code (game clock was night at the time, see). That bug is fixed. Still haven't converted all floating messages to Orthographic yet.

 

What's new:

Extended Camera

• Camera has wider range of motion
  
• Camera is now centered just above player head (only tested on human - other races let me know how it works)
  
• *** use a perspective of around .45 for this option
  

Follow Cam

• Camera follows the character as it turns
  
• When the option is first enabled the camera moved directly behind player
  
• Works great with Extended Camera
  

Ortho Banners

• Because the game would be *ugly* without it I have folded the Orthographic patch into this one
  

New Configuration Options

• Extended and Follow Camera options are now in Video tab at the top
  
• The Orthographic Banners option is not configurable. So there
  

Other Stuff

• Follow cam is a bit herky jerky due to the limited directions the character can face. I'll see if I can smooth it out a bit
  
• The Video tab is now overflowing. Can anyone suggest where else to put these options?
  
• The camera height could be made adjustable so that players can make it work for their race.
  
• Check out how things look from Directly overhead - Classic Warcraft
  
• New configuration options are disabled by default
  
• The current client does not render everything you should be able to see right away if the camera changes too much (those who use the current high perspective camera know this) just move the character or your mouse and that will fix itself.
  

Here's some screenies. To make overshoulder usable I think that clicking on your char should generate a movement somewhere in front of the character... either that or alpha-ing the character and allowing clicks to pass through him to the scene. Both are possible client side modifications.

 

 

 

Source may come later... but I want feedback first. This modification changes only 7 digits in draw_scene.c so I may just post the modifications here.

 

So far I've tested movement, passing though doors, combat, and subsequently I navigated out of the underworld... so its useable.

Edited July 25, 2006 by emajekral

[trollson]

The over-the-shoulder looks really excellent! Its how I would expect the world to look.

 

Some concerns of how this maps to the game at the moment (which have been raised before when first person views have been discussed):

• Obviously, this is not how the maps where designed to be viewed, so there may be issues which would take a few iterations to sort out.
  
• The client is only informed about entities relatively close by, so they will appear from nowhere in the near distance. If the client was informed about "low detail" entities to a greater distance (no names, just vague shape and size)?
  
• Far distances needs something added. Maybe a backdrop image at least?
  
• Cant see whats behind you! Though "radar" minimap may help.
  
• This may make it too obvious how flat the world is (6.2m range in units of 0.2m from the map editor). Upping the height map range to the full-bytes worth (51m range?) or even increase to two-bytes (13km!) may give more definition.
  

Edited July 13, 2006 by trollson

[kl4Uz]

looks amazing

[Placid]

The over-the-shoulder looks really excellent! Its how I would expect the world to look.

Agreed. I LOVE the first person perspective. I think it really adds depth and style to the game.

 

• Far distances needs something added. Maybe a backdrop image at least?
  

Could a fog or 'blackout' not be a decent enough solution? (assuming it isn't too intensive for the computer)

[Roja]

The shoulder view does look great! Thanks for trying this out!

note: If this does make it into the client, it would be another viewing option, and would not take the place of any current possible view.

 

To address "the game wasn't meant to be viewed this way"-which is correct, these are the things the game lacks:

 

1. real 3d terrain (this would be the hardest thing to add)

2. skybox (probably not difficult to add if you know how to do it)

3. some of the objects don't have undersides (easy to change).

4. there would need to be some sort of "how many static objects to view at once" option. Faster machine's you can turn it up, so you can see farther, slower, turn it down so you'd just see a fog.

[Learner]

The shoulder view does look great! Thanks for trying this out!

 

To address "the game wasn't meant to be viewed this way"-which is correct, these are the things the game lacks:

 

1. real 3d terrain (this would be the hardest thing to add)

2. skybox (probably not difficult to add if you know how to do it)

3. some of the objects don't have undersides (easy to change).

4. there would need to be some sort of "how many static objects to view at once" option. Faster machine's you can turn it up, so you can see farther, slower, turn it down so you'd just see a fog.

There also needs to be a LOD (Level Of Detail) feature so that smaller objects farther away dont get rendered.

[trollson]

Level of Detail:

 

It would be nice to use fractal models for objects, but thats a bit of a heavy change.

 

Could the current 3D object be extended to have levels of resolution? Think of a tree; just reduced down to a brown line and green blob beyond a certain distance.

 

Possibly create lower resolution slices automagically by subsampling the polygons in the current format? Something would still have to be done about the textures though (no point rendering a image down to 1x1 pixel).

 

At worse, static objects could be just 2D images after a certain distance.

Edited July 13, 2006 by trollson

[Roja]

 

There also needs to be a LOD (Level Of Detail) feature so that smaller objects farther away dont get rendered.

 

That's what I meant by #4

[Learner]

 

There also needs to be a LOD (Level Of Detail) feature so that smaller objects farther away dont get rendered.

 

That's what I meant by #4

I changed it from "how many" to which based on size & distance

[emajekral]

I have added a patch for my camera modifications. See the top of the thread for details.

 

click here for patch

[trollson]

Fog: Quick search, there is an opengl extension GL_EXT_fog_coord for eye-distance fog which seems to be intended for this purpose.

 

Sample Code: fogcoord.c.

 

Example Screenshots: OpenGL Fog Coord Example (the pic links to a zip containing demo program for win32, exe and source).

 

 

Heightmaps: What does happen if we have a elm file with a height map that exceeds the +4m limit (still within the byte-sized storage though).

Edited July 13, 2006 by trollson

[Roja]

sounds great, can't wait to test it

 

My suggestion for the video tab: make a separate Camera tab.

[emajekral]

Fog: Quick search, there is an opengl extension GL_EXT_fog_coord for eye-distance fog which seems to be intended for this purpose.

 

Sample Code: fogcoord.c.

 

Example Screenshots: OpenGL Fog Coord Example (the pic links to a zip containing demo program for win32, exe and source).

 

 

Heightmaps: What does happen if we have a elm file with a height map that exceeds the +4m limit (still within the byte-sized storage though).

 

 

 

We already have fog, and people turn it off so they can hunt. I'm pretty sure messing with the fog we have will interfere with rain events, etc. for those who do leave it enabled.

 

I'll look at height maps and see if I can plug a fractal generator into it to create some variation for interest. Expect this to take me a week or so. I may be able extend the height maps we have without breaking anything.

 

I work full time, so I may be unable to get to any of this done at all. Wish me luck.

 

Up until now I have been coding and testing under Linux. I'm about to install dev-c++ and the needed libraries in WinXP to test and debug there. I'll post again when that's done.

 

We have a policy against posting links to binaries, right?

[Roja]

you can post binaries. As long as people use them only on the test server it's ok.

 

 

The problem with height maps is i'd imagine it'd require a new map format, a new map editor, all the old maps would have to be fixed to look good on a height map(unless we only use 3d terrain for new maps)....basically, a ton of work

Of course, I wish you luck nonetheless!

Even if it will only work on new maps, it'd be very cool to have.

[trollson]

From my reading of the code:

 

The current elm format uses a byte to store height map values; 0-255 if char is unsigned, else -127-127, this is not specified and depends (platform dependant, but not relevant for the given application).

 

The map editor only creates maps with height values 0-31 (-2.2m to +4.0m, 0.2m units).

 

The client doesnt seem to care about this restriction. It just treats the value as is.

So, can we create a map file which uses the full dynamic range and see what happens?

I'd suggest creating a copy of IP's elm, and adding an offset height map. Constraints would be:

• values of zero (0) must be preserved.
  
• adjacent & adjacent diagonal height differences of <=1 must be preserved as <=1
  
• walkable gradients need to be preserved (adjacent z difference of <=2 units or 0.4m).
  
• adjust the z-pos value for all 2&3D objects, particles, lights, according to the change in height map under them.
  

My guess is that it would still all work, although aesthetics may suffer. But then, there may be some crinkles in the works.

 

Btw, if the height map in increased to two bytes, it would give 13km dynamic range. Plenty unless you need Everest and the Marianas trench on the same map (+9km, -13km).

Edited July 15, 2006 by trollson

[Learner]

From my reading of the code:

 

The current elm format uses a byte to store height map values; 0-255 if char is unsigned, else -127-127, this is not specified and depends (platform dependant, but not relevant for the given application).

 

The map editor only creates maps with height values 0-31 (-2.2m to +4.0m, 0.2m units).

 

The client doesnt seem to care about this restriction. It just treats the value as is.

So, can we create a map file which uses the full dynamic range and see what happens?

I'd suggest creating a copy of IP's elm, and adding an offset height map. Constraints would be:

• values of zero (0) must be preserved.
  
• adjacent & adjacent diagonal height differences of <=1 must be preserved as <=1.
  
• adjust the z-pos value for all 2&3D objects, particles, lights, according to the change in height map under them.
  

My guess is that it would still all work, although aesthetics may suffer. But then, there may be some crinkles in the works.

 

Btw, if the height map in increased to two bytes, it would give 13km dynamic range. Plenty unless you need Everest and the Marianas trench on the same map (+9km, -13km).

Do not attempt to change the map file format or use the unused bits in the height map. Any changes will break the server that must load ALL maps into memory and uses the reserved bits.

[Roja]

There's much more to the 3d terrain/height map & map format than meets the eye...a few more problems with it:

 

1. 2d objects would all have to be deleted

2. terrain texture blending would be needed

 

If you'd like to do some other patch, I think a more realistic goal would be to create a skybox with a dynamic sky, instead of a height map. Not that I know much about this stuff..I'm not a programmer, but from what I do know making real 3d terrain will be a huge project.

[trollson]

Do not attempt to change the map file format or use the unused bits in the height map. Any changes will break the server that must load ALL maps into memory and uses the reserved bits.

The suggestion is not for server side or production use, but just to see how an increase heightmap would appear on the client with minimum effort.

 

Why would the 2D objects need to be deleted?

[Placid]

Ugh, didn't have much fun applying this patch.

Is there any reason why you are including changes to files such as:

• CVS/Entries
  
• CVS/Entries.log
  
• languages/de/CVS/Entries
  
• languages/de/CVS/Entries.log
  

(Amongst others)

 

Any chance of a cleaner patch, with just the above changes?

[Roja]

 

Why would the 2D objects need to be deleted?

 

Picture 3d terrain. Now, picture flat 2d objects on top of that terrain.

[Learner]

Do not attempt to change the map file format or use the unused bits in the height map. Any changes will break the server that must load ALL maps into memory and uses the reserved bits.

The suggestion is not for server side or production use, but just to see how an increase heightmap would appear on the client with minimum effort.

 

Why would the 2D objects need to be deleted?

To prevent problems the client and server use exactly the same map files. Otherwise you could get a whole load of bugs because of one little difference! So, at this time we can't consider an experimental change to the map. If you can do it just in the client, then play away.

[trollson]

Picture 3d terrain. Now, picture flat 2d objects on top of that terrain.

Which is why I said to adjust the z-pos value for all objects according to the change in height map under them.

 

Though for rotatable objects, it may be necessary to apply a rotation to match a change in surface normal. But not always, and the distinction isnt in the map file (a compromise could be inferred from object type and current rotation, but not guarenteed). I'd put this under 'crinkles to be worked out' afterall, this is just for evaluation.

 

As for object id; these being taken from their position in the vectors in the map file. This type of bulk manipulation wouldnt change ordering.

 

What differences are left? If the server uses height advantage as a combat adjustment then this would not match the client's modified map. So long as walkable gradients are preserved, the client pathfinding will match (we'd want to walk around and try different povs). Actually, this last constraint is the tricky part...

[emajekral]

Uh oh! I knew someone would notice I don't know what I'm doing.

Has anyone successfully applied the patch and tested it?

 

There's a bug with some floating messages that I know how to fix when I fix the diff file I'll include the change, and get rid of some extraneous console output.

 

Ugh, didn't have much fun applying this patch.

Is there any reason why you are including changes to files such as:

• CVS/Entries
  
• CVS/Entries.log
  
• languages/de/CVS/Entries
  
• languages/de/CVS/Entries.log
  

(Amongst others)

 

Any chance of a cleaner patch, with just the above changes?

 

Probably because my dev code is a week out of date and I'm doing a blind "diff -Naur" against the most recent CVS code. CVS is new to me. I'll try to clean it up. Anyone willing to provide a step by step on how to provide the cleanest possible diff for patching?

 

For now I'm applying the patch as

cd elc
patch -p2 < patchname

 

Don't ask why I'm diffing from so far up my tree.

 

As for height maps... I forgot about the 2D objects. I'll leave it on the back burner for awhile. The changes I had planned would have left map files alone and just jittered some vertices on the z axis in client: slow but tweakable.

 

Sky boxes have been on my mind while at work. Good suggestion.

[Placid]

Can you not just `diff -Naur` in the ELC directory? (Note, i'm certainly no CVS expert either, but thats usually the base dir I use to create/apply diffs)

[ttlanhil]

cvs has the ability to make diffs. in most cases, that's the best option (it knows what files to compare, etc)

 

cvs diff -Nuar > patchfile.patch

 

note that the options can be set in a cvs settings file in $HOME, in which case you don't need to specify them, and that you can chose which files to diff... in the example, none are given, so it does all in CVS. you could, instead:

 

cvs diff actors.c