Jump to content


Photo

Camera Modifications (Roja this is for you)


  • Please log in to reply
70 replies to this topic

#1 emajekral

emajekral

    Skunk

  • Members
  • 111 posts

Posted 13 July 2006 - 03:05 AM

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 :D
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 :D
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.

Posted Image

Posted Image

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 by emajekral, 25 July 2006 - 01:58 AM.


#2 trollson

trollson

    Puma

  • Members
  • 1290 posts
  • Gender:Male
  • Location:Hampshire, UK
  • Interests:40 yrs RPG & Wargames,
    Former Senior Scientist (MOD, 1990-2000),
    Scientific Software (25 yrs).

Posted 13 July 2006 - 06:41 AM

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 by trollson, 13 July 2006 - 06:49 AM.


#3 kl4Uz

kl4Uz

    Skeleton

  • Members
  • 1075 posts
  • Location:europa

Posted 13 July 2006 - 11:32 AM

looks amazing :wub:

#4 Placid

Placid

    Snowball?

  • Members
  • 5077 posts
  • Location:UK
  • Interests:meh

Posted 13 July 2006 - 11:54 AM

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)

#5 Roja

Roja

    Unicorn

  • Admin
  • 8802 posts
  • Gender:Not Telling

Posted 13 July 2006 - 12:24 PM

The shoulder view does look great! Thanks for trying this out! :wub:
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.

#6 Learner

Learner

    Ant

  • Admin
  • 5433 posts
  • Gender:Male
  • Location:MN, USA
  • Interests:Persistent RPG

Posted 13 July 2006 - 12:26 PM

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

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.

#7 trollson

trollson

    Puma

  • Members
  • 1290 posts
  • Gender:Male
  • Location:Hampshire, UK
  • Interests:40 yrs RPG & Wargames,
    Former Senior Scientist (MOD, 1990-2000),
    Scientific Software (25 yrs).

Posted 13 July 2006 - 01:23 PM

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 by trollson, 13 July 2006 - 01:27 PM.


#8 Roja

Roja

    Unicorn

  • Admin
  • 8802 posts
  • Gender:Not Telling

Posted 13 July 2006 - 01:50 PM

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 :wub:

#9 Learner

Learner

    Ant

  • Admin
  • 5433 posts
  • Gender:Male
  • Location:MN, USA
  • Interests:Persistent RPG

Posted 13 July 2006 - 01:51 PM



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 :wub:

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

#10 emajekral

emajekral

    Skunk

  • Members
  • 111 posts

Posted 13 July 2006 - 04:12 PM

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

click here for patch

#11 trollson

trollson

    Puma

  • Members
  • 1290 posts
  • Gender:Male
  • Location:Hampshire, UK
  • Interests:40 yrs RPG & Wargames,
    Former Senior Scientist (MOD, 1990-2000),
    Scientific Software (25 yrs).

Posted 13 July 2006 - 04:30 PM

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 by trollson, 13 July 2006 - 05:00 PM.


#12 Roja

Roja

    Unicorn

  • Admin
  • 8802 posts
  • Gender:Not Telling

Posted 13 July 2006 - 04:38 PM

sounds great, can't wait to test it :P

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

#13 emajekral

emajekral

    Skunk

  • Members
  • 111 posts

Posted 13 July 2006 - 05:08 PM

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?

#14 Roja

Roja

    Unicorn

  • Admin
  • 8802 posts
  • Gender:Not Telling

Posted 13 July 2006 - 05:43 PM

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 :D
Of course, I wish you luck nonetheless! :ph34r:
Even if it will only work on new maps, it'd be very cool to have.

#15 trollson

trollson

    Puma

  • Members
  • 1290 posts
  • Gender:Male
  • Location:Hampshire, UK
  • Interests:40 yrs RPG & Wargames,
    Former Senior Scientist (MOD, 1990-2000),
    Scientific Software (25 yrs).

Posted 13 July 2006 - 08:18 PM

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 by trollson, 15 July 2006 - 12:58 PM.


#16 Learner

Learner

    Ant

  • Admin
  • 5433 posts
  • Gender:Male
  • Location:MN, USA
  • Interests:Persistent RPG

Posted 13 July 2006 - 08:51 PM

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.

#17 Roja

Roja

    Unicorn

  • Admin
  • 8802 posts
  • Gender:Not Telling

Posted 13 July 2006 - 09:23 PM

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.

#18 trollson

trollson

    Puma

  • Members
  • 1290 posts
  • Gender:Male
  • Location:Hampshire, UK
  • Interests:40 yrs RPG & Wargames,
    Former Senior Scientist (MOD, 1990-2000),
    Scientific Software (25 yrs).

Posted 13 July 2006 - 09:36 PM

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?

#19 Placid

Placid

    Snowball?

  • Members
  • 5077 posts
  • Location:UK
  • Interests:meh

Posted 13 July 2006 - 10:08 PM

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?

#20 Roja

Roja

    Unicorn

  • Admin
  • 8802 posts
  • Gender:Not Telling

Posted 13 July 2006 - 10:18 PM

Why would the 2D objects need to be deleted?


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




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users