Coordinates System

Oct 26, 2009 at 9:43 PM

I am having trouble getting my arms around the coordinate system in use on screen in Balder.  I am trying to place a series of concentric rings at increasing heights.  When I place tham at increasing Y, they descend.  If I change the sign of the Y value, they ascend.  Can you provide a primer on the coordimate system and how the scene renders objects at coordinates?

Coordinator
Oct 27, 2009 at 6:53 AM

Hi,

this started out as a bug - and still sort of is. We've never gotten around to prioritize it. We will be providing the ability to choose your coordinate system. I need to finish a couple of things myself before I can look at that, but I'll see with one of the other developers if we can nail it very soon. Then we'll provide a primer on how it all works. 

Oct 27, 2009 at 1:01 PM

OK...thanks.  If I wanted to look over the code for coordinate transforms, what classes would I look at?

Can you also help me understand how to define normals and texture coordinates?

Coordinator
Oct 27, 2009 at 2:55 PM

All transforms are done in the Vector and Matrix class found in Math. 

The rendering pipeline relies on the View and Projection matrix found in Camera. Every node renders itself, so Geometry would be the endpoint in the pipeline you'd have to look at, which then calls the GeometryContext that is device specific, and for Silverlight is in the Balder.Silverlight project.

 

As for Normals and Texture Coordinates, normals can be per Vertex or per Face, they are located respectively on each of these types.

TextureCoordinates are index based, during creation /loading, these are set through the GeometryContext.

Oct 27, 2009 at 6:41 PM

How are z-order and z-index handled?

Is there a way to set the z-order/z-index of an object?

Coordinator
Oct 27, 2009 at 7:04 PM

Do you mean z-index in the Silverlight sense?  Meaning that you want it sorted in front or in back of other Silverlight elements?

That is a limitation at the moment. Specific objects within a scene can't be sorted within the Silverlight rendering pipeline. 
When I finish what I'm working on right now, you'll be able to have an Object in your Xaml called a "RenderingContainer", this can then be sorted in Silverlight. All you would need to do then would be to set the background color with transparency and you could have it as a natural part of your Silverlight app.

Also, with the new RenderingContainer I'm brining in soon, you'll be able to have more than one container, so you could have multiple objects sorted against the Silverlight UI elements. Allthough, one needs to be careful with this, as every container seriously could impact the performance - one would need to look at the rendering dimension to limit the size of it.

The reason for this limitation, is that we're not using Silverlight primitives for rendering - earlier we used the Silverlight rendering pipeline for all polygons, but it was too slow and we wrote a "software" rendering engine instead, so we're actually drawing the pixels ourselves. 

Coordinator
Oct 28, 2009 at 7:31 PM

The solution has been pushed to GitHub. 

I'll probably be pushing a new version of Balder tomorrow and a tutorial of how to use the new Xaml syntax. With the new syntax and a refactoring done, one can now have multiple Scenes running on different portions of the screen.

Oct 29, 2009 at 2:09 PM

I am trying to understabnd how things are placed within the coordinate system, and how they are ordered (I am used to thinking about them in terms of z-index or z-order, from SIlverlight).  I am assuming that you are not ordering them, simply positioning them and then if they are in the viewport, the natural order of the coordinate system will enforce object placement, based on Camera placement.  So this brings me back to the bug that you mentioned regarding coordinate systems.  Can you help me understand that bug and its impact? 

Coordinator
Oct 30, 2009 at 7:51 AM

Thats correct. Any primitives rendered are rendered according to their world location relative to the view (Camera).  

As for the bug. I consider it a bug, but in fact its a valid coordinate system, but not what most people are used to. It comes with a history from my part, its what I have been used to.  

The coordinate system is on the Y axis flipped, so positive Y coordinates are pointing downwards and negative upwards. Positive X coordinates are to the right, positive Z coordinates points away from you. The coordinate system only needs to be flipped on the Y axis. I haven't prioritized this yet, but feel a strong urge to do so very soon and enable one to pick the preferred coordinate system.

As for units within the coordinate system. This is up to you to define.

Oct 30, 2009 at 5:37 PM
Edited Oct 30, 2009 at 5:38 PM

That explanation clarifies things a lot.   I am used to what amounts to old VGA coordinates, x and y in the screen plane, z perpindicular to the screen, with positive y up and positive z out of the screen. It is all arbitrary as well, as long as I understand the base system.

Nov 14, 2009 at 3:35 AM

Thanks,I have been also puzzled for a long time about the coordinate system.  According to your explanation, your world coordinate system is similar to the device coordinate . x points right ,y points downwards and z points back into  the screen .

Coordinator
Nov 14, 2009 at 9:44 AM

For now its like this. But it will change in the next release. Then positive Y will point upwards.

Dec 3, 2009 at 2:08 PM

Re-reading this post raises a question that I need to have clarified.  If the coordinates are positive y up, positive z into the screen and positive x to the right, then we are using a left-handed coordinate system.  Handedness being defined as the direction of the normal defined by crossing unit vector along x with the unit vector along y.  This should result in a unit vector along positive z.  In this coordinate system, the unit vector points along negative z.  Please verify if this is correct.

Coordinator
Dec 4, 2009 at 9:19 PM

Hi,

I'll look this over during the weekend, maybe I screwed up the math when I "fixed" this. Your assumption is correct for the LH coordinate system and it should be positive Z.

I will be working on a bunch of sample applications, so that I can discover things like this at a much earlier stage. 

Coordinator
Dec 4, 2009 at 10:22 PM

After some investigating, I think I'm not reading your question correct.  :)

The coordinate system seems to be to be acting as at least I'm expecting it to do, with a positive Z moving away from the view (into the screen), which would be the correct behavior for a left-handed : 

http://www.evl.uic.edu/ralph/508S98/coordinates.html

lefty.gif