Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 10 Oct 2005
Offline Last Active Today, 01:51 PM

#5244157 Simple inheritance

Posted by haegarr on 02 August 2015 - 09:34 AM

what shouldn't be happening?
he said, " It only sees the implementation if I include the .cpp file of the class A" that had the definition. No surprise there.

The reported linker errors shouldn't happen, and including an implementation file from an implementation file should not be done in general. It hints at a wrong project set-up. Either the sense of partial project compilation is lost, or else (legitimate) linker errors occur as soon as the base class is inherited from more than 1 derived class.


probably looking for something like this.
B myB;

Although this is a valid invocation, doing like so is (a) not necessary for the given problem situation, and (b) hides a potential problem. Such invocation states explicitly that A::foo should be invoked even in the case that B::foo exists! That implies that the client has a deep understanding of the inner working of the class hierarchy; woe betide anyone who does this invocation without good reason. The situation that B does not override A::foo is definitely not a good reason alone. So mentioning this kind of "solution" should be done with the respective warning what actually happens.


and btw, when you implement a derived virtual, it doesn't 'overwrite' the base implementation. It will still be there.

With respect to the C++11 keyword, an allowed term would be "overriding".

#5243895 Hierarchy of meshes and entities

Posted by haegarr on 31 July 2015 - 03:02 PM

I'm not particularly familiar with Ogre, so I'm not necessarily a good reference here. To be honest, looking at the interfaces of Ogre::Entity and Ogre::Mesh, for example, does not make me happy from an architectural point of view.


I guess that Entity holds its own hierarchy of nodes and sub-meshes attached to them [...]

Perhaps, but it may be different. Normally a sub-mesh is defined as a separate set of vertexes for which another material is used, so this leads to another draw call. A weapon, on the other hand, is an own entity: It may be held in a hand but also dropped down onto the floor. This is different from a sub-mesh.

#5243793 OpenGL- Render to texture- a specific area of screen

Posted by haegarr on 31 July 2015 - 08:03 AM

You have to set the projection and view matrices so that "your camera sees what you want to render" into the texture. You have to use glViewPort and perhaps glScissor to which area of the texture rendering goes. 

#5243792 Hierarchy of meshes and entities

Posted by haegarr on 31 July 2015 - 07:57 AM

Why does it matter? I thought it will be more easy for the "engine user" to refer and work with just names and not indices.

It matters because string comparison costs around an order of magnitude more performance. If you want strings at runtime, then you can compute the hash of the string once and hand over both the string and the hash value for example in a "Name" structure.


BTW: Hashes are not indices.


It is recursive. Here's are the implementations:

It is not a mistake or so, but it tastes curious that "findSceneNode" checks the own node's name. Personally I'd let the routine test only child nodes and that directly.


Also what are node paths and why would I need them?

Each node need to be uniquely addressable. Because your search is recursive you need names not only unique within the couple of direct child nodes but over the entire scene graph. One possibility is to mimic what hierarchical file-systems do: Using a path like "/root/child_at_1st_level/child_at_2nd_level/my_node_of_interest". That would be a node path, because it addresses the node of interest using the names of the parents instead of constructing a name like "my_node_of_interest_with_a_super_long_and_hence_hopefully_unique_name". Notice that especially naming sub-nodes would be close to impossible as soon as several instances of a model are set into the scene if not using a path like scheme.


[...]The logic behind having more than one mesh attached to a SceneNode is for attaching swords to hands, MAGs to tanks etc., so when the hand rotates so will the sword.[...]

That would not be possible. Such things need to be child nodes because they need their own transform (local-to-parent transform) which is definitely part of the node but not the mesh.


Why would I care about adding order of child nodes?

As said: Its okay the way you do it as long as you do not need an order. I just wanted to hint at that.


Where else can I load the data from storage?

The resource management should have a loader object for this kind of thing.


I actually have Caches of materials inside Mesh. Like Cache etc.

Well, if your mesh class is actually a model then it is probably okay besides that another name should be chosen. (An actual mesh should not need to know about materials.)

#5243342 From openGL to various 3D format

Posted by haegarr on 29 July 2015 - 02:53 AM

1)in my code i'm using some Glut built-in methods and function to create object such as glutSolidTeapot() , glutSolidCube() etc .. I would like to know if i can "export" them to one of the formats named up above. If not , should i build my own functions to display them , so i can have the vertices position and save them in the files.

I do not know a way to ask the models from OpenGL besides interception. You can download a GLUT source code from internet, e.g. here, and extract the mesh data (consiering any copyright, of course).


But I also do not see what this should be good for. Generating a cube is easy, and the teapot (like any hundreds of other meshes) can be loaded from the internet (e.g. here as OBJ).


2)i'm already done with the obj parsing , but i have no clue on how the PLY and VRML files behave , i could use a little help here please , thanks !

The specifications can be found on the internet, e.g. here for PLY. What exactly do you want to know?


However: I'm surprised of your intent.

a) Does PLY really play a role nowadays?

b) VRML is superseded by X3D. Besides that … VRML / X3D is a beast! 

c) OBJ and PLY are both supported by AssImp for both import and export.

#5243174 Hierarchy of meshes and entities

Posted by haegarr on 28 July 2015 - 08:44 AM

So I could have a SceneManager class, with all the object in a single array, and then the separated scene graph hierarchy will have nodes that only point to the objects in the SceneManager class?

Something along this, yes.


See, there are many possible ways to structure the world. Spatial vicinity, several parent-child relations, static vs. dynamic objects, groups of belonging colliders, … whatever. The solution is not to try to create the one omnipotent structure, trying to fulfill all needs but ending in a solution that fulfills each need to 80% at best. Instead each sub-system should drive its own structure that is best suited to do its job. That means to have say an octree to solve spatial vicinity problems, several dependency trees, perhaps several groups of belonging colliders, and so on. That is what L. Spiro says e.g. with "a scene graph is not for rendering".

#5243122 Texture Issues With Unusual Internal Formats

Posted by haegarr on 28 July 2015 - 01:28 AM

There are many things that may go wrong. The first candidate coming to my mind is the pixel unpack alignment. With each texel being 2 bytes in size and the chance that you transfer an odd number of texels per row, the default alignment of 4 will not match. Have you considered glPixelStorei(GL_UNPACK_ALIGNMENT, 2) yet? Alternatively, do you do some padding?

#5243011 How do you manage assets?

Posted by haegarr on 27 July 2015 - 12:00 PM

This question has been discussion many times already. Searching for "asset manage" or "resource manage" will give you plenty of hits. There you can find much about caches and loaders. However, many if not most of them suggest to manage assets separated by type. Why exactly do you feel it being wrong? 

#5243000 compositing images.

Posted by haegarr on 27 July 2015 - 10:47 AM

Hmm, a 2D skeletal system? I didn't consider this, [...]

Its not exactly a skeleton, because a skeleton animates bone by bone, while the suggested system animates the armature at once. It is closer to sprite animation but supports exchangeable parts.


[...] iirc spline is a tool that can do this. Might give this a shot, thanks for the suggestion.

Its named Spine.

#5242982 compositing images.

Posted by haegarr on 27 July 2015 - 09:37 AM

Rendering such a character and crafting it (i.e. a tool and/or workflow to do so) are two different things.


You can animate / render such a character as a cut-out figure with an armature. Let's say there is an object of the Figure class. The object provides a pointer to an instance of the Armature class as well as a couple of slots, one for each cut-out graphic. An armature is just a spatially arranged set of 2D anchors. For each (possible) anchor there is a cut-out graphic slot available within the Figure object. Each cut-graphic has a 2D pivot which is thought to spatially match the corresponding anchor in the armature. At every turn, the animation system picks the current Armature instance and links it into the Figure object. Rendering is done by iterating the filled slots in order and drawing the belonging graphic at the placement as described by the corresponding armature anchor.


In fact the above thing is similar to a 2D skeleton animation except that not bones but the entire pose is written by the animation track. However, it allows to combine the graphics independently from the animation. It further allows to animate the graphics in flip-book manner, too; just let another (selected) animation track set the cut-out graphic slot in the Figure object.

#5242909 Rotating a sprite toward mouse [SFML]

Posted by haegarr on 27 July 2015 - 01:29 AM

Are mousePos and shipSprite.getPosition given in the same space? I.e. are both in screen space or are both in world space? The mouse position is driven by sf::Mouse::getPosition which results in window co-ordinates. On the other hand, a sprite position is usually given in world space which may differ dramatically from screen space. Now, because you compute the difference of the two positions, you need to make sure that both are in the same space.

#5242754 Hierarchy of meshes and entities

Posted by haegarr on 26 July 2015 - 08:18 AM

First of, many of the term you've thrown in are not unambiguously defined without a clear context, e.g. the DCC or game engine.


- Meshes must be loaded once per object. (e.g "big_sword.mesh" should not be loaded twice from the file).

Yes, a mesh is a resource (like a texture, a sound, …). It need to exist only once in memory to be used for several game objects. This does not necessarily mean that there is no copy. For example, you may have a copy in system memory and a copy in GPU memory. Although often loaded from a file, a mesh may also be generated procedurally or by processing a template mesh (e.g. skinning on the CPU).


- Entities are basically 3d world transformations that represent loaded meshes?

The term "entity" is not clear. Nowadays with the popular ECS (entity component system), an "entity" very often means a game object. As such an entity (in combination with its components) is much more, not to say it can be everything. Of course, you can look at an entity class (i.e. the implementation of the basic concept) and see as little as an identifier. Perhaps you even understand "entity" as an instantiation of something within the world / scene.


Regardless of the definition of entity, I would never claim that "3d world transformations" do "represent loaded meshes". A transformation has a right on its own. It can be used to place a game object in the world / scene, and hence serve as spatial anchor where and how a mesh is located therein.


- Meshes can contain nodes and skeleton data [...]

Well, from a pragmatic point of view this may be true, but it smells like bad practice. A mesh is a resource in its own right; it can exists with or without a skeleton besides it. A skeleton is an utility to transform a mesh. It can exist without a mesh. …  Bringing skeleton and mesh together is meant to create a binding. True, if a mesh is thought to be bound to a skeleton, the mesh often brings binding weights with it because the elements of the mesh (i.e. vertexes) are the targets of the transforms.


[…] while the nodes are "trackable" by the coder so that different meshes can be attached to them. [...]

In my engine such attachment possibilities are separate components of a game object. I use a GripComponent component as part of a game object that represent an item, and a GrabComponent component as part of a game object that can hold such an item. The GrabComponent has a transform that attached to a bone (of the skeleton), and when grabbing a link is established from the GrabComponent to the GripComponent, giving an extraordinary kind of parenting.


I'm not sure what exactly is the different between entities and nodes. Can anyone shed some light over this?

Hope the above explanation does so. If not, then please specify more exactly what your term "entity" means.

#5242435 OpenGL 2.1 Gimbal lock

Posted by haegarr on 24 July 2015 - 10:37 AM

I admit that judging the rotation is a bit problematic now ;)

However, I'm a bit confused now. In the OP there is the routine Teapot::PrintObj(). It has a pair of glPushMatrix() / glPopMatrix() what made me thought that before Teapot::PrintObj() is invoked just the view matrix is on the stack. But then the new rotation as was active with post #5 should have worked well. Because you've reported that it does spin endlessly, I concluded that the push / pop was replaced. Perhaps not … my mistake.
Unfortunately I cannot see the entire relevant code. So I tell how it should look like.
a) Before Teapot::PrintObj() is invoked, only the view matrix is on the matrix stack.
b) Inside Teapot::PrintObj() and before any transformation is put on the stack, a glPushMatrix() is done.
c) The 1st transform is the glTranslate() as shown in the OP.
d) The 2nd transform is a glMultMatrix() with R (no glLoadIdentity() nor glLoadMatrix() here).
e) The 3rd transform is the glScale() as shown in the OP.
f) Then perform the rendering.
g) Before leaving Teapot::PrintObj() do glPopMatrix().
If the code follows those scheme, and the  teapot still spins "without reason", then the problem lies perhaps in the input section. E.g. the Dn from above is allowed to differ from the identity matrix if and only if the user actually causes a rotation (i.e. you must not accumulate onto the angle used to compute Dn; the angle is either a delta angle when the belonging key is pressed (or whatever), or it is zero if not).

#5242410 Capture what is Rendered in OpenGL

Posted by haegarr on 24 July 2015 - 08:56 AM

is your suggestion still suitable for me?

Yes. You do a 1st rendering pass with the folded mesh, into a texture attachment of an FBO. Then you do a 2nd render pass with mesh #2 (the orange quadrangle in the 2nd picture) with a texture mapping, and the bound texture is the one which was the render target in the 1st pass. So, the same texture is written in the 1st pass and read in the 2nd pass. That is the typical application of render to texture.

#5242382 OpenGL 2.1 Gimbal lock

Posted by haegarr on 24 July 2015 - 07:08 AM

There is at least one issue:


That R is a matrix that differs from the identity matrix as soon as the first angle different from 0 is applied as transformation. So it follows the formula accordingly to my post above:

      Rn := Dn * Rn-1


You apply it (as far as the shown code snippet let me follow the implementation) by multiplying it with the current matrix M on the stack:

      Mn := Rn * Mn-1


Now, what happens at the next time step?

     Mn+1 := Rn+1 * Mn = Dn+1 * RnMn


However, it should have been something different, namely

     Dn+1 * Rn

because R already accumulates all the incremental rotations (your solution accumulates them twice, in R and in M).


Therefore you either need to load the identity matrix (glLoadIdentity) before doing the glMultMatrix, so that

     Mn := Rn * I

or else you use the shortcut to replace the current top matrix on the stack with your own by using glLoadMatrix, so that

     Mn := Rn

BTW: The glMultMatrix and glLoadMatrix functions exist for float argument arrays, too; using them would unburden you from doing a float to double conversion.