FIFE forums

Please login or register.

Login with username, password and session length
Advanced search  

News:

FIFE 0.4.0 has been released on 15th of January, 2017!

Author Topic: View module design docs & patches  (Read 6354 times)

Sleek

  • Developer
  • Jr. Member
  • *
  • Posts: 57
    • View Profile
View module design docs & patches
« on: January 08, 2008, 08:15:24 pm »

After quite a while of meddling with the view code, I believe I have come to an understanding of most of it's working. I made a few changes here and there, and as there is not really any specs/standard specified in the wiki, I chose arbitrarily ( and slightly taking the original code in mind ) a number of key designs.

Here are the patches:

all.diff


(Updated on 16th Jan 2008, 2pm GMT)



It's by no means a clean patch for commit action, but let's look at it & review early. I'll post better versions from time to time. Also see the bottom of this post for other patches.

Changes :
#1 - transformation matrices ( load, apply, multiply & actual application in camera.cpp )
The original code seems to apply matrix transformation in an inverse way. The usual method of applying transformation is :
Code: [Select]
M = Transformation Matrix
P = Point(coordinate) in 3D space
P' = Transformed coordinate

P' = M x P
In the old codebase, it's P' = Minverse x P. I still am not sure if the original coder meant to transform the camera instead of the model, n. If this is true, I am happy to revert my changes to Camera::updateMatrices.

And just FYI, if R= Rotate Matrix, T= Tilt Matrix, Tr= Translate Matrix,
a sequence of rotation->translate->tilt is represented by the formula below:
Code: [Select]
M= T x Tr x R  // Rotation first, Tilt last
#2 - copy constructor to convert between Matrix<int> & Matrix<double>
This is simply a way to do Matrix<double/int> m1( Matrix<int/double> m2 ). I might implement this also for PointType2D<int/double> & PointType3D<int/double>.

#3 - how transformation is applied in toLayerCoordinates/toExactLayerCoordinates & toElevationCoordinates
See #1. This is simply a reversal from P' = Minverse x P to P' = M x P

#4 - moved out ScreenPoint -> ElevationCoordinate conversion into python script instead
Will comment later on this one.

#5 - cellgrid's transformation sequence
I am not sure about this one yet. There are multiple ways to do it and it doesn't really matter. It will affect how mappers align their cellgrids though. We should go for the most intuitive sequence ( as viewed in the editor ).

#6 - text colour for CoordinateRenderer
Changed to white. It's easier for me to see it in dark/colourful maps.

#7 - getAngleBetween in InstanceRenderer
Will comment on this after further testing & comparison

#8 - moved function definition from camera.h to camera.cpp
For faster compilation if any changes are made to the functions. This is also the right thing to do.

#9 - updateReferenceScale in camera.cpp
The camera.reference_scale variable affects how 'zoomed' our map is. It's a totally different variable compared to the camera.zoom variable. Basically, it allows us to specify at zoom=Z, we want this object to be this big. I thought of several ways this can be useful for game devs. He might want to specify how many grids should appear across the screen width. He could also mean that at zoom=1, 10 pixels should equal to 2cm on the screen.  I am hoping to get it to work so that our objects appear of the constant size across all resolutions. This is not really important. The current code by jasoka works as well. The bouncing effect is not to be worried about.

#10 - added a number of checks for invalid pointers in various functions
For added security :)


« Last Edit: January 16, 2008, 08:16:38 am by Sleek »
Logged

Sleek

  • Developer
  • Jr. Member
  • *
  • Posts: 57
    • View Profile
Re: View module design docs
« Reply #1 on: January 09, 2008, 08:36:36 pm »

Okay here's my early draft for the view design doc.

Background info
===============
Prerequisites: background info on elevation, layer, camera


Handedness
The handedness of a coordinate system determines how the axes grow from the origin. There are only 2 of them: left or right. Those who have taken higher chemistry classes might find this familiar with the term 'chiralty'. [1]

our engine
=======================
#1 - Relationship between elevation, layer(cellgrid) and screen coordinate system.
Each exists in their own coordinate space.  Since each layer is contained within an elevation, layer->elevation coordinate mapping can be done. This is also what happens when an instance is drawn. A layer->elevation->screen coordinate mapping is used to find the screen coordinate of an instance and draw it.


Layer coordinate transformation sequence is rotate->scale->translate for easy visibility on changes during mapping. Keep this in mind when you are adjusting cellgrids for a map. Transformation on the layer coordinate is visually independent of the elevation coordinate space.


Elevation coordinate transformation is translate->scale->rotate->tilt. Transformation on elevation coordinate will have a visual effect on layer/cellgrid coordinate space.


Lastly ,we have the screen coordinate, which is basically the coordinate space on which everything is drawn. take note that although it says 'screen', it's not a 2d space. It's in fact, 3D. the elevation->screencoord transformation maps the model coordinate onto actual pixels for rendering. Thus, the z-coord of a screencoordinate is in pixels unit.


#2 - Coordinate system and transformation

All coordinate spaces are left-handed. The most important feature is that the y-axis increases downward instead of upward (in keeping with SDL coordinate ). Another point is that z-axis increases as it goes out of the screen into the observer's face.

Our transformation matrix reflects the left-handed transformation. for example, our rotation matrix looks something similar to this(left side):


* from http://www.cprogramming.com/tutorial/3d/rotation.html

Rotations at positive angle around a left-handed axes is shown here,



#3 - Camera positioning & movement


The camera, at 0 angle and constant reference scale, is located at a constant z-coord. The reference scale specifies that at certain zoom value, how much of an area is viewed through the viewport. Changing the camera's location will only change it's (x,y) value. The camera is also capable of infinite(almost  ;D ) zoom/scale factor. Tilting the camera keeps it's pointing vector at the same magnitude. However, the camera itself moves around the elevation x-axis (range:[0,-90] for now, with the vector changing direction to keep pointing at it's x,y location.



When a camera rotates, the camera pointing vector also changes while the magnitude is preserved. The camera position range & movement can be described in a circular track around  it's location[2]. However, the track of which the camera follows will depend on the tilt value. At tilt value of 90, the track's z-coord is 0.




My comments
=====================
[1] Transformation matrix between a left-hand & right hand coordinates system will differ, and thus we need to choose one that we are comfortable with and stick with that. From the original codebase, I found that a left-handed transformation matrix was used in LoadRotate. So, we will use left-handed coordinate axes for the rest of the time.

[2]Remember, a camera's location is the layer coordinate of which is viewed  at the center of the camera's viewport.


« Last Edit: January 11, 2008, 06:55:26 pm by Sleek »
Logged

mvBarracuda

  • Administrator
  • Sr. Member
  • *
  • Posts: 411
    • View Profile
Re: View module design docs
« Reply #2 on: January 10, 2008, 03:49:14 am »

You've done a great job with the explanation images sleek :-) You definately got a hand for them. Any plans to bring this documentation to the wiki later as well?

This article should be the right place at the wiki though there is still a bunch of outdated information there back from the time when phoku initially wrote down his thoughts about the view module over one year ago:
http://wiki.fifengine.net/index.php?title=View_Design_Documentation
Logged

Sleek

  • Developer
  • Jr. Member
  • *
  • Posts: 57
    • View Profile
Re: View module design docs
« Reply #3 on: January 11, 2008, 02:56:21 am »

I'll be moving these to the wiki later barra. Wiki formatting scares me sometimes, but I guess it's a better place than here. I kind of want people to discuss and comment if they noticed that something is not right though.
Logged

jasoka

  • Developer
  • Jr. Member
  • *
  • Posts: 51
    • View Profile
Re: View module design docs
« Reply #4 on: January 12, 2008, 09:42:47 am »

Nice work with the docs and rendering in general, sleek :) I see that this particular task needs quite much concentration, thinking and testing, and you are making good progress for the target of having well behaving rendering for fife.
Logged

Sleek

  • Developer
  • Jr. Member
  • *
  • Posts: 57
    • View Profile
Re: View module design docs & patches
« Reply #5 on: January 15, 2008, 07:30:47 am »

Thanks jasoka for the comment.

*bump* for update above.
Logged

jasoka

  • Developer
  • Jr. Member
  • *
  • Posts: 51
    • View Profile
Re: View module design docs & patches
« Reply #6 on: January 15, 2008, 12:45:34 pm »

hmm.. looks I cannot access the diffs above. Perhaps there's something wrong with the links / rights?
Logged

Sleek

  • Developer
  • Jr. Member
  • *
  • Posts: 57
    • View Profile
Re: View module design docs & patches
« Reply #7 on: January 15, 2008, 01:22:31 pm »

Sorry, should be okay now.
Logged

jasoka

  • Developer
  • Jr. Member
  • *
  • Posts: 51
    • View Profile
Re: View module design docs & patches
« Reply #8 on: January 15, 2008, 04:31:15 pm »

Thanks. I checked the diffs quickly through (in editor only), and in case changes seem to bring improvements to view behavior, I would go ahead and commit them to svn. There were couple of points that could be adjusted, but we can do that later. There's plenty to tweak anyway in the engine, so no need to hold functional improvements due to stylistic issues.
Logged

Sleek

  • Developer
  • Jr. Member
  • *
  • Posts: 57
    • View Profile
Re: View module design docs & patches
« Reply #9 on: January 16, 2008, 12:27:09 am »

Cool. I'll commit it when I get back home.

On to another feature I would like to code into the view module; Instance visibility behind walls. What I propose is to have a 'visible-behind-objects' flag in Instance classes, e.g. for the PC. The render sequence will go as usual, but whenever a 'visible' instance is encountered, it is rendered, and then the render surface the size of the instance's bounding box is copied onto a list. The list's content is then imposed under a translucent-transparent sphere & then drawn at the end of the render sequence. Details below:


Beekeeper Instance rendered



Beekeeper Image rect is read into a buffer. Transparency effect is applied outside the border of the circle shown. This transparency will later blend with the wall image in front of the Beekeeper to produce smooth see-through effect.


The next Instance is drawn as usual. The 2nd image above will later be drawn on top of the most front wall.
Logged

mvBarracuda

  • Administrator
  • Sr. Member
  • *
  • Posts: 411
    • View Profile
Re: View module design docs & patches
« Reply #10 on: January 16, 2008, 02:57:19 am »

That sounds like a nice feature sleek :-) I remember that the Fallout engine supported it as well and it was quite useful for picking up items that were lying behind walls and other wall-like map instances.
Logged