Jump to content

  • Log In with Google      Sign In   
  • Create Account

haegarr

Member Since 10 Oct 2005
Offline Last Active Today, 12:42 AM

Posts I've Made

In Topic: <OpenGL/gl.h> Include Failing

01 May 2016 - 09:20 AM

It is not exactly clear to me what build system you are using. It is Xcode itself? If yes, then adding "/System/Library/Frameworks/" should not be needed.

 

However, the frameworks therein are runtime components. The headers are development components - the are not bundled with the runtime components. Instead, they are bundled with the SDKs. For example, the SDK for Mac OS X 10.9 brings such headers

 

Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/OpenGL.framework/Versions/A/Headers/gl.h

Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/OpenGL.framework/Versions/A/Headers/gl3.h


In Topic: OpenGL - Render Plane equation

01 May 2016 - 03:08 AM

I don't know how your framework linearizes matrices, so this code snippet
   Matrix4 rot = new Matrix4(...) 

may or may not be correct.

 

But there is a noticeable difference in transformation computation between your 1st and your 2nd post. In the 1st post you compute

    Mi+1 := Mi * T * R

with M being the transformation matrix on the stack, T being the translation and R the rotation. The snippet in your 2nd post computes

    Mi+1 := I * R * T

instead, where I is the identity matrix. Notice that (a) the matrix being formerly on the top of the stack is now ignored, and that (b) the order of translation and rotation is exchanged.

 

Hence try to change this line

   Matrix4 result = rot * trans;

into 

   Matrix4 result = trans * rot;

 
Further, if the former stack matrix should play a role, instead of 
   GL.LoadMatrix(result.OpenGL);
use
   GL.MultMatrix(result.OpenGL);

In Topic: OpenGL - Render Plane equation

01 May 2016 - 01:18 AM

Your doubts are valid, but the reason is wrong. The vertices are placed onto the local x/y plane, hence the normal is along the direction of the local z axis. Putting (0,0,1) into your rotation code and considering that rotation by 360° is identical to rotation by 0°, you correctly see the front of your plane. However, just using normals along x (1,0,0) or y (0,1,0) or so with your rotation code still give you the same vertices, since all transformations are the same. Changing the order of rotation does not make any difference then.

 

Actually, using a normal and a distance lets several degrees of freedom in an open state. Rendering a plane with vertices need those degree of freedom to be fixed. What I mean is that you need a definition of

a) an origin of the plane, so that there is a point with local co-ordinates (0,0,0), 

b) an orientation angle around the normal (think of the rolling angle of a camera; the normal gives you just 2 of the 3 angles).

 

You solved a) by using the point

   origin := (0,0,0) + distance * normal

 

You solve b) by just picking an angle, i.e. so that rolling is zero.

 

So with these fixes you have a position and an orientation as a direction and "no rolling". Let's express "no rolling" as

   up_vector := (0,1,0)
And instead of a pure direction, let's use it as difference vector from the origin to a tip point

   center_point := origin + normal * 1

 

Now (with the origin and the center point and the up vector), what we have here are the ingredients for the gluLookAt function! Although being described as a function to compute a view matrix, the function actually just builds a transformation matrix with a translation and rotations so that the z axis points in a specific direction.

 

The math behind the gluLookAt function isn't complicated and leaving OpenGL's matrix stack behind is ever a Good Thing TM, but I assume you may be happy with the sketched solution. Otherwise feel free to ask :)


In Topic: Engine Subsystems calling each other

24 April 2016 - 06:28 AM

The inconvenience of passing a pointer around is not a sufficient reasoning for tolerating the evilness of globals or singletons!

 

It is common that sub-systems depend on other sub-systems. These dependencies should be directed and acyclic, i.e. a lower level sub-system should never ever call a higher level sub-system. Moreover, a sub-system is not necessarily represented by a single class; from a naming point of view, a "system" is always understood as elements that work together to collectively fulfill a specific task. Graphical rendering, for example, is often implemented as a process passing through several layers and done in several steps: Iterating the scene and collecting renderable entities (perhaps restricted to a specific kind), culling them by visibility, converting them from high level "models" to meshes and textures and shaders, sorting them by some performance criteria, and then sending them to the wrapper behind which the 3rd party graphics API is hidden.

 

I understood the Map class that is mentioned in several posts of the OP as a game level. As such it is a high level data structure (not a sub-system at all, of course). The wrapper for graphical rendering API is a lowest level thing. Hence giving the wrapper a Map instance is already a design flaw.

 

In the end, when a well defined structure of sub-systems is instantiated, pointers need to be passed around for sure. After instantiation, the sub-systems know where their serving sub-systems are, and the need for passing pointers exists just for runtime varying things.

 

Just my 2 cents, of course.


In Topic: Help with python :(

23 April 2016 - 11:49 PM

A key in an associative array need to be defined. In your case the key is given by a variable which itself is not defined.

 

a) The key defined by a string literal:

John_Smith = { "name": "John Smith" }

print(John_Smith["name"])
b) The key defined by a string variable: 
name = "name"
John_Smith = { name: "John Smith" }

print(John_Smith["name"])
print(John_Smith[name])

PARTNERS