Graphic engine and graphic technologies

[chuck_starchaser]

I have code of my own for singleton, which unlike most singletons out there it properly self-destroys during static deallocation. Instead of a static pointer to instance I use a static std::auto_ptr. But if it's working, never mind, or I can improve it later. I like the cube approach; I was thinking of a sub-triangled soccer ball geometry; would have been a lot more work.

[rewpparo]

here is a screenshot of my plugin where you can see the structure very well

of course it's far from finished. I have no global texturing (hense the tiling), no normals (that's where I got stuck in the end), etc. But LOD generation is working, it was promising.

As for singletons, yes I believe we can change the system later. The important part is that ther is a common singleton system in vega strike so that people don't have to wonder "how do I get this singleton again ?". All singletons should be handled the same way. I really can't wait for that boost library...... it would be the ideal solution.

[klauss]

Perhaps, I was thinking, a quick way to integrate VS with Ogre would be uploading the meshes to Ogre in PostProcessBlabla(), which is performed right after a mesh loads, either from xmesh or bfxm. That function (in mesh_xml.cpp) actually uploads the mesh from the temporary storage in mesh_xml to the actual Mesh object. Now, instead, you would upload it to Ogre (do any conversions required). Then, make every instance out of the drawing queue by default, and replace Mesh::Draw() by a simple call to Ogre telling it to activate the mesh. Then, GameStarSystem::ProcessDrawQueue(), which handles all the rendering stuff, would tell Ogre to render.

If I knew something about Ogre I could try that, but it seems you know it better. Feel free to mail me at klaussfreire at gmail d0t com if you have doubts about the engine.

Once you have VS working with Ogre, you can cleanup, and try your luck at using your graphicEngine class. But I would suggest designing prior to coding. Porting VS to Ogre quickly as I said before would give you an understanding of what VS needs, which would guide your design of graphicEngine to a more sensible state. You wouldn't want to finish coding graphicEngine to find out, in the end, that something you did renders it incompatible with VS (who knows what it could be, but wouldn't be the first time a design is incompatible with another one).

[rewpparo]

Well i was thinking of integrating it one step before that. XML parsing would be done by the engine. I want to have everything that is remotely related to graphics in the engine, it's the only way to keep the code clean, and the integration easy in the long term.

I would like to design the interface between ogre and VS more to vs's liking, but I honestly can't understand the beginning of VS's current engine, as there isn't a clear interface between VS and it's graphic engine. The design of my work is very clear in my head, but you're right, I'm totally in the dark as to where are the critical points of VS where the integration will actually take place. Any help in that domain will be greatly appreciated. If you want to know more about my interface, I can send you my work so far.
As for total incompatibilities, I don't believe we'll get any, as my work is pretty straightforward. What might happen is problems like I used quaternions to set object orientation, while VS uses angles, or whatever. But a conversion function should do the trick if that were to happen. If we have real incompatibilities, they will be between Ogre and VS, so there wouldn't be anything I can do about it. But then again, I doubt that will happen.

[rewpparo]

Well, my blender seems to have gone on strike, and I'd need the VS sphere mesh used for planets in the ogre format for a test.. if someone has blender and the importer, could he export it to ogre's format and upload it somewhere, or send it to loursmathurin at hotmail dot com ? that would help a lot, and might even allow me to upload the first screenshots
the blender exporter in in the ogre package, ogrenew/Tools/BlenderExport and the importer is here http://www.geocities.com/cubofjudahslion/VS/xmesh.zip

[CubOfJudahsLion]

The script doesn't work with 2.37, but I'm working on it now (I need it too.) Today (well, in my GMT-6 timezone) a new version should be up.

[chuck_starchaser]

Well, my blender seems to have gone on strike, and I'd need the VS sphere mesh used for planets in the ogre format for a test.. if someone has blender and the importer, could he export it to ogre's format and upload it somewhere, or send it to loursmathurin at hotmail dot com ? that would help a lot, and might even allow me to upload the first screenshots
the blender exporter in in the ogre package, ogrenew/Tools/BlenderExport and the importer is here http://www.geocities.com/cubofjudahslion/VS/xmesh.zip

I believe the planet sphere is generated by code; I think I remember seeing a function somewhere that produced it. I'll see if I can find it again.

[www2]

The script doesn't work with 2.37, but I'm working on it now (I need it too.) Today (well, in my GMT-6 timezone) a new version should be up.

I hev the same problem with bender V2.37a.

[rewpparo]

The script doesn't work with 2.37, but I'm working on it now (I need it too.) Today (well, in my GMT-6 timezone) a new version should be up.

Then my blender is actually working ? cool ^^ thanks a lot for your script, it's very usefull, and I guess I'll be using it a lot. Waiting for your next version

[klauss]

Spheres are generated on demand. It's really simple. You can just create any sphere with blender and use it, if you need a mesh (but making Ogre generate the sphere also would be a nice thing - so you can have tons of LODs)

[CubOfJudahsLion]

Then my blender is actually working ? cool ^^ thanks a lot for your script, it's very usefull, and I guess I'll be using it a lot. Waiting for your next version

I hev the same problem with bender V2.37a.

You're welcome. I have a working version now (they just renamed the library) that also solves the texture problems of previous versions or it seems so far (I really haven't tested it extensively yet), but I want to remove duplicate vertexes automatically. So far I haven't found a function/method that does that. Looks like I'll have to write code to do it manually (grrrrr.)

[chuck_starchaser]

How's it going newpparo? Managed to get spheres in? Sorry, I looked for where planets come from but couldn't find it. I'm just not good at understanding other people's code. I can barely understand mine after a few months, and that even though I spend hours sometimes trying to figure out the best way to name a function... >:0

[Halleck]

It's not as if the sphere VS uses has to be the exact same one used in the ogre test. The simplest way to go about this might be to just create a new sphere by whatever means and map a vs planet texture to it.

While you're at it, try a tesselated sphere made out of tris instead of the standard one made out of quads, they have a more uniform resolution.

While we're on the topic of spheres, here's a relevant link:
http://astronomy.swin.edu.au/~pbourke/modelling/sphere/

[rewpparo]

I tried to make my own sphere on blender, bu I really can't find my way around this software ^^ I really an no modeler As I had internet trouble, I couldn't get a tutorial, so I decided to go for sphere generation. That requires to add a new type of object to Ogre, and that requires a plugin. I'm having difficulties with that too, but nothing time won't solve, now that my internet is back. Geez i'm paralysed wthout internet.....
Anyways, The VS SCeneManager plugin for ogre is on it's way, it will implement the ogre fine tunig we need for VS.
I'll check out the paper about sphere generation, I have some papers that are specifically oriented towards planet generation too (including dynamic LOD).
I'll upload screenshots as soon as I have something worth showing

[chuck_starchaser]

I feel your pain. When I was working on my glsl Earth experiment I never got a sphere that worked properly: I used a sphere I found in the net, as well as the standard one from glut, and both showed a missing last wedge for me. The source for spheres in the link above only computes the points, as far as I can see; not the geometry. I spent days googling around for a working sphere and came up empty-handed; and couldn't figure out how the VS engine does it, either. I hope you have better luck.

[Zeog]

I made a python script once, in which I generated a 3D animated sphere for some surface waves. I generated the sphere by tesselating an icosahedron. The code provides the vertices for the points as well as all the triangles (and all the physics and animation stuff). Could that vertex generation and triangle-finding part of the code be any help?

You would have to translate it to C++ though...

[pifactorial]

I tried to make my own sphere on blender, bu I really can't find my way around this software

Isn't it just:
[SPACE] -> Add -> Mesh -> (Iso/UV)Sphere

[rewpparo]

^^ yeah I did that but my problem was with texture mapping. Found a tutorial, I'm on it now But I just can't manage to export my uv mapping to my ogre mesh... well whatever, I think it's going to be faster for me to code the sphere than to model it ^^

zeog : thanks for the offer, but the code is very ogre specific for that part, and the generation of the sphere itself is kinda straightforward for what I'll do right now. And I have no knowledge whatsoever about python ^^ I only code c++

[chuck_starchaser]

newpparo, I have a glsl solution for that. I computed uv coords in the vertex shader...

Code: Select all

const float pi = 3.1415926535897932384626433832795;
const float two_pi = 6.28318530717958647692528676655901;
const float one_over_two_pi = 0.159154943091895335768883763372514;
const float half_pi = 1.57079632679489661923132169163975;
const float three_half_pi = 4.71238898038468985769396507491925;

varying float reflect_dot;
varying float cos_view_to_normal_angle;
varying float cos_light_to_normal_angle;
varying float cos_view_to_light_angle;

uniform vec3 camera_pos;
uniform float cloud_rotation;

void main()
{
 //GENERATE TEXTURE COORDINATES (NOT PRESENT IN SPHERIC MODEL)
 // (NOTE: All these calculations are done in model space.)
 // Compute longitude in radians, latitude is okay as z (the
 // sphere model from glut I'm using has axis along z coord).
 vec4 v4 = normalize(vec4(gl_Vertex.xyz,0.0));
 vec4 v4squared = v4*v4;
 float longitude;
 // If the longitude is within +/-45 degrees, we use atan(x/y);
 // else we use atan(y/x), to avoid imprecision with large numbers
 if( dot(v4squared,v4squared) < 0.000001 )
 {
  longitude = pi;
 }
 else
 {
  if( v4squared.x > v4squared.y )
  {
   if( v4.x >= 0.0 ) longitude = atan(v4.y/v4.x);
   else longitude = pi - (atan(v4.y/(-v4.x)));
  }
  else
  {
   if( v4.y >= 0.0 ) longitude = half_pi -(atan(v4.x/v4.y));
   else longitude = three_half_pi + (atan(v4.x/(-v4.y)));
  }
 }
 //translate radians to cycles
 longitude *= one_over_two_pi;
 // Make sure we haven't got a number in a range outside 0-360 deg.
 if( longitude < 0.0 ) longitude += 1.0;
 if( longitude >= 1.0 ) longitude -= 1.0;
 // First we do ground texture coordinates. Note that v4.z has a range
 // of from -1 to +1; but we need a texture range from 0 to 1. We also
 // need our longitude spanning 0-1, but it's in radians, so /2pi ...
 gl_TexCoord[0].x = longitude;
 gl_TexCoord[0].y = clamp( 0.5-0.5*v4.z, 0.001, 0.999);

Or, you can use the same math to generate u,v's for the sphere itself.

[rewpparo]

Hey keep in mind hat it's just a test I'm doing, i'd like to keep the number of features I use as low as possible ^^ I'll keep your script at hand, it may prove usefull in the future, but I'd prefer to use only basic material support for now, mainly because I don't have quite the same level of expertise there, I'll be more cautious. (yes vertex programs are in the material too ^^ everything is in the material in Ogre ^^)

[chuck_starchaser]

But at the end I also said, you can use the same math as I'm using in the shader, to compute u,v's for the mesh. Essentially what I'm doing there is taking the coord of each vertex and computing texture coords.
For v you can use y (or z), whichever is the coord going through the poles, and scale it to fit a 0.0 to 1.0 range.
Fur u it's a bit more complicated, but not too hard.
Assume the equator is in the xy plane:
y/x is the tangent of the angle from "Greewich".
So, you could theoretically divide y by x and then take the arc-tan.
Problem is that in two places x is zero, so you get undefined.
What I did in that shader code was to compare the absolute values of x and y. If abs(x), or |x|, is greater than |y|, I'd compute arctan(y/x).
If |x| is less than |y|, I compute arccotan(x/y), but the function arccot() is not available, but it is equivalent, anyhow, to 90 degress - arctan(x/y).
And arctan returns a value in radians, which, to translate to cycles, you need to multiply by the inverse of 2pi.

[rewpparo]

Yep I certainly will do that

Right now I'm kinda stuck with my plugin, I got an error that prevents me from going forward.
just to keep you up to date on the structure, the engine I'm designing has two parts : an ogre plugin and a high level API.
The plugin implements low level objects like the sphere with automatic LOD generation, or miscelandelous self modifying shapes in the future, and customisations to the engine itself (like z buffering if I have to modify anything)
The High level API will be the interface between Ogre and vega strike. It provides objects like planets, stars and ships that wil create the necessary low level objects (meshes, billboards, ....) and provide an interface to move the objects around and customise material and properties.

So my error is with the very beginning of the plugin (I fail to register it properly in ogre, if someone thinks he can help : http://www.ogre3d.org/phpBB2/viewtopic.php?t=11505 It must be some sort of a runtime linking problem, it's not too ogre specific)
So in the meantime I'll keep going on with the high end API, which shouldn't take too long BTW, and brush up on my knowledge of graphic technologies. Talking with you guys made me realise how retarded I am in that area ^^ As soon as I get help to solve my problem, I can start coding the plugin again.

[rewpparo]

Okay, I'm designing the ship interface now, and i'd like some input to design something that can be integrated into VS easily. if someone could point me to where the ship parts are loaded ie where the basic mesh is loaded, and equipment parsed and loaded into the graphic engine, to make guns etc appearant. I also need your input on this design, if you think it's close enough to the way VS does things

What I intend to do is a graphicShip class, with methods to change materials on the whole ship or parts of it. It will also have an explode() method, and other eye candy stuff.

Also, I intend to make a createHardPoint method, that will create a graphicHardPoint class containing a position relative to the ship, and a mesh to load at said position. That mesh can be rotated freely, made to fire a shot in its current dicrection, and customised at will (change the mesh/material if damaged, erase it if destroyed,...)

Also one more question : does vs mesh format support submeshes ? I made a method in the graphicShip that changes material only on one part of the ship, given its name. I wanted to know if VS format supported that.

[klauss]

First of all, VS uses a hierarchy of "units" - not meshes. Each unit has its own mesh list, all of which are drawn with the unit's "cumulative transform", which is the transform that places the unit correctly, accounting for the hierarchy.

Basically, in your graphicUnit (like graphicShip) you would need support for hierarchy: subunits. graphicUnits inside a graphicUnit would inherit transforms (both traslation, rotation and scaling).

I'm not particularly fond of that idea, since that would duplicate the hierarchy (first in VS' units, which cannot be part of the graphic engine since they also keep other state variables, and second in your graphic engine).

Perhaps, the transform method used now (with matrices and stuff) should be kept as is, since it also solves problems with huge scales (all objects are represented around a local origin). Rather, the graphicMesh would just render itself given a transform matrix. That way, you don't worry about subunits.

About submeshes (further division of single meshes into multiple parts), do that as you please, VS won't be hassled (since right now meshes are a single entity). A unit may have multiple meshes, BTW. That's how some sort of "submesh" is implemented.

All the code is in unit_*.cpp and mesh_*.cpp, I think.
But VS code is not particularly well compartmentalized, IMHO. All things connect to each other. One side effect of migration to Ogre, a very good one, IMO, is that it would result in much better code separation.

Also, FYI, Meshes in VS stand for a collection of primitives sharing the same texture. So BFXM files expand to multiple meshes

Anyway, it's a complex issue. I repeat, if I were you, I would play with VegaStrike's current engine to get a feeling of things.

[rewpparo]

I use the same kind of hierarchy. All my graphicMesh, graphicShip and so on inherit a graphicObject class that has all the position and rotation methods, as well as preloading / preUnloading methods (scaling is easy to add). so units can use that, meshes can use the high level objects like ship and stuff.


the way I see it :


So yes it adds compartmentalization, but it doesn't really duplicate the hierarchy. And it's the basis for a clean structure, that we can then spread around.

As for local coordinates and sich, that's already taken care of too. Each object is the child of something. In a binary star system, one sun is child of the other, planets are children of the main sun, moons are children of their planet, etc... So everything is in local coordinates, and by moving the main sun around, you move the whole system. and you can still move the sun's mesh and stuff without interfering with the system.

Klauss, don't suppose ogre can't do it, and that we should keep the existing system. Ogre can do more than you think, and my goal is to make it do all you can think of ! So explain the problems, so that I can find a solution. I really want to do this stuff ^^ Anyhow, Thanks for your input, this is the kind of problems I'd like to hear about

as for submeshes, the way Ogre does things is, I think, a bit more evolved than what you do. A unit can of course have multiple meshes, with the hierarchy you want. but even in one mesh (say a ship) some parts of it can be tagged. they can then be rendered separately, with a different texture, and so on. This allows for example players to customise their ships by putting one material on the nose, one on the right wing, another one on the left one, etc...
however, one thing I agree on, I should brush up my VS terminology and rename some of my classes to make them more "VS style". objects will become units, and such. I'll rename some of my methods too.