Graphic engine and graphic technologies

[charlieg]

You've done something wrong if you have to be root to compile it. I would hope Fedora's development tools aren't that messed up and I'm pretty certain OGRE's build process issn't so convoluted that you need to be root to do anything.

Did you download or decompress the tarball when you were root?

[chuck_starchaser]

I never login as root, ever. What I do is su when I need to. I doubt very much I could have opened the tarball as root. To do so I would have had to call file-roller from a root command line, and I wouldn't even know what the command line name for file-roller is.

EDIT:
Just wondering, the first day I installed FC3 I may have created my downloads folder or something from the command line while su'd as root. If I did so, would that make the folder (on my user's desktop) inaccessible to me as user?
Well, now that I think about it, I'm often root at the console because usually the first thing I do when I login is yum update; so probably a lot of the libraries and stuff I've installed I've installed as root.
(Why does Linux expect users to know so many things?)

[rewpparo]

Linux doesn't expect the user to know so many things, just the administrator so use root only when you have no other way to do what you want. It's a good thing to only use su, but if you use it all the time, you might as well log in as root ^^
basicaly I use su only to install software, system wide libs, or to change system wide configuration.
As for your problem, check the properties of your directories. if you created them as root, then root is the owner, even in /home. Depending on permission, you might not be able to write there. You can change the owner when root, set it to you username, that should do the trick. I don't know where it is as you probably use gnome (I use KDE).
And be carefull what you do when su'ed

And just to confirm : I built Ogre yesterday, I only needed to su for the make install step, as it installs the libs system-wide. and I exit'ed right after that.

[rewpparo]

One thing I didn't say about ogre is that it specializes in 3D, and is a very weak in terms of GUI. I'm investigating crazy eddie's gui system, a lib that seems quite impressive to render any kind of GUI within a 3D API. It is designed to be used with Ogre, and completes the toolset very efficiently.
http://www.cegui.org.uk take a look at the screenshots and features

EDIT : ok for those of you compiling ogre, try to compile CrazyEddie's Gui before you do. Having it installed will make a new sample compile : Gui. Then you can have a look and tell me when you would have expected such a highly configurable GUI system if you had to code it yourselves ^^

[chuck_starchaser]

Starting to look to me like I'd better download Fedora Core 4 and re-incarnate...

[rewpparo]

well if you wish, but I believe just changing the permissions for the required files shouldn't take too long. There must be a recursive way to do it somewhere in you GUI.
Oh and when you do compile ogre, make sure you have a look at the CubeMapping Sample, and play a bit with the options they tell you you have on the top right corner. I think you'll like that

[chuck_starchaser]

Wow! Serious? They got a dynamic cube map example? Gotta get that! Okay; I'm gonna install FC4, but in about a week; I have to learn sql in a rush right now, besides, I don't have a dvd burner, which I think I need for the FC4 installer. Nah, they ought to have CD images, I'm sure...

[rewpparo]

yes, I downloaded CD isos last week for FC4. I didn't install it in the end 'caus it was gnome based, but you can install it from CDs. takes 4 of them

[rewpparo]

Ok I had a closest look at the source of vegastrike, and I must say it's hard to find your way in there ! ^^
I believe what we could do is a graphicEngine class, with methods to start/stop the engine, load systems and units, and classes for the graphical implementation of units, that would be membre of the present unit classes It would be a lot clearer than the present implementation where all the functions are scattered across numerous other classes. if that's ok with you, I'll start working on a prototype, however I'm not sure I can integrate that prototype into VS. As i said the code is quite obscure.
One more issue : Shall I integrate your physics inside this manager, or shall I leave them outside ?

[chuck_starchaser]

I'd say leave the physics out, because, if my info is correct, the physics engine runs at a lower frame rate than the rendering, 14Hz comes to mind.
Thanks for doing this. If I can help you with code let me know; I can't help with knowledge cause I got none, either of VS or Ogre. I'm sure klauss will give you a hand with integration when you are ready for it; he figured out the vs engine in no time at all. And organize it the way you think it's best; meshes, textures materials and all that were slated for major overhaul, so don't worry about trying to match the present organization. We were thinking about introducing shaders before you showed up, and were planning to make frag shaders part of materials, vertex shaders part of the meshes, and shader programs part of units, fyi. Also we were struggling with the paradox that textures should belong to materials, yet texture coords are specified by the mesh, and sometimes the unit specifies a decal, but the mesh specifies where the decal goes... >:O ..I'm not *completely* useless, though, I love design in C++, and I'm almost as good as Lint++ at picking up lint. Throw me the files once a week and I'll criticize them for ya --no, I'd be glad to help with parts of the design if you're able to offshoot any.

[rewpparo]

Actually Ogre has it's own ressources systems, material scripts and so on. it's been given 4 years of thinking, so I think it must be pretty polished.
Basically you have the model in a .mesh file, material in a .material file, and takes directly .cg programs, declared in the material script.
Check out the ogre manual for details :
http://www.ogre3d.org/docs/manual/manua ... C_Contents

Of course converting meshes and materials to the ogre format will be an issue, but it shouldn't be a problem if you still have either the sources or an importer from your format to any 3D modeler. Ogre can export his mesh format from virtually any modeler.
As for high level scripts, I believe I can use them the way they are now.
Wait until I finish to thank me though, as I can't guarantee I'll finish anything. I'm busy with my work, and at the end of july I'm going abroad. I'll be back in october. so no guarantee I'll be able to hand over a complete work.
Also let me remind you that i'm not an experienced programer, so even given the time, I don't know if I can pull this through. But I'll give it a try ! Thanks for your help and support

something I already need to know is the methods you need to acces in the engine.. I'll start with createStarSystem and CreateUnitt, if you could point me to where the corresponding parsers are implemented in VS, that would help.

[chuck_starchaser]

I think I've read Simbad has added or is adding GLSL; we had no plans of even looking at Cg, AFAIK.
R.e. meshes, I believe we're quite attached to our in-house bfxm format, which is another thing ready for an overhaul; but I guess this would be a matter of writing a plugin, right?
FYI, there's some of us at the WCU mod forum trying to figure out SQLite for a possible replacement for xml. If we succeed there, we might do the same for Vegastrike. So everything is in a state of flux, presently. But I'll see if I can find where those parsers are.

[klauss]

mesh_xml.cpp is the one you're looking for, but mesh loading is sparsed around many files. You may want to look trhough mesh_bfm.cpp, which is the one actually being used (xml handles xmesh parsing, but there are no xmesh files left, they're all bfxm, which gets loadd by mesh_bfm.cpp).

[rewpparo]

Ok I'll look into that. But before I start to load meshes, i'm still looking around to find how a star is drawn. is it a sphere mesh and aa billboard for corona ? where do they get the data from ? that kind of things.
For now I have basic initialisation working, and a method to render one frame, that should be called from the main loop, and a test program to test those features in controled environment.
Now I'm trying to load some VS style objects from VS data. I found the parsers that make stars, i'll look through to find out what I want.
As for meshes, I'll try to make a parser for xmeshes, but I won't disactivate ogre meshes, so both will be aviable as input. It's not that hard to suppor both, so I might as well do it, you'll choose then what you want to do.

EDIT : I went through the said parsers, and I see how you get options from the XML file. However, I was expecting some sort of a createEyeCandy functions that would declare the actual objects to openGL, but I can't find it. I can't find a class that parses the unit classes for options and creates those objects either. So I don't really know where to look to find the actual graphic composition of the objects, or how the parameters are taken into account. can someone give me a pointer ?

[chuck_starchaser]

That's one question I can at least partially answer. There are several ways in which planets are represented. They all share in common a sphere for the ground, but some have a second sphere for the atmosphere and/or clouds, some are using a funnel-shaped thing in front of them, like a billboard but not flat (lighting considerations) for the atmo; some use a flat billboard for the atmo, and many have yet another mesh behind for the halo. The halo is called "halo" in the code; but the billboards and funnels for atmo are called "fog" or even "fawg". But don't worry about it: Did you see my Earth using glsl? Look for a thread in the Art subforum titled "shady planet". I managed to do ground, clouds, atmosphere AND halo, all projected onto one sphere.
And, by the way, any chance we can have glsl instead of cg with ogre?

[klauss]

Coronas are ugly. They get created by creating the light, and not the star. And they're always placed at 0,0,0 - I know, it's ugly. I wanted to change it a while ago, but I never got the time to do it. I don't remember exactly where that took place, though.

As for meshes, there's some passing from the xml mesh to the actual mesh somewhere (I think it's PostProcessSometing() in mesh_xml.cpp), that loads vertex data and everything to the Mesh object. From there, you have to look at mesh.cpp and other mesh_xx.cpp files - the main one that sends things to OGL is RefreshDisplayList() and BeginDrawState(). The ones that actually draw things are the different Draw(), which set up the draw queue, and finally ProcessDrawQueue(), which actually draws things (DrawNow() is a copy of ProcessDrawQueue() which also draws things).

[rewpparo]

Thanks guys, I'll look into all that

As for your question chunck

[ogre]Supports vertex and fragment programs (shaders), both low-level programs written in assembler, and high-level programs written in Cg, DirectX9 HLSL, or GLSL and provides automatic support for many commonly bound constant parameters like worldview matrices, light state information, object space eye position etc

it's in the features page
I don't know much about shaders and stuff, but my guess is that if ogre supports asm, it supports all high level programs, as they all get translated into asm when compiled..

[hellcatv]

this is all very encouraging talk...
I would simply love to have Vega Strike use a separate engine to render the 3d objects...
it will be tricky to coax it into using the right precision and setting the z-buffer ranges appropriately....
but I suspect if we get it working without the long range z-buffer we will have already made enough of a stride that we can figure out a minimal patch to the original source (or plugin as the case may be) to make things work properly.

On the other hand this seems like no small task--right now I can't even think of where I'd start in integrating this new renderer...

the VS renderer is simple--but once you start taking the intricacies of the file format loading and putting them into a different loader you take with you the onus of providing Vega Strike with nice collision meshes for the physics system ,etc.
it's too bad Ogre does not take display lists from OpenGL to render--- or vertex buffer objects...
perhaps that's too GL specific.

well I'm certainly open to ideas about how someone could get started on this project---
it's either this or reorganizing our engine with shaders like chuck and klauss proposed... we'll have to see which project materializes first--then which project actually gets finished first

[hellcatv]

as for thread safety--I'm not as confident as you folks that "making vega strike multithreaded" will clean up the code and make it nice and bug free---I hate to point out that the actual number of (not-by-design) bugs most players get is really quite low...
multithreaded code is really tricky--and I'm no good at it... it would require an engine rewrite with MT in mind unless it were limited to just 1 facet of the engine (eg sound as it is now).

it's a shame to put the additional processors to waste (remember Intel 2010 manycore) , maybe we can have that one simulating a dynamic universe, something that woudln't require much communication with the main engine.

[chuck_starchaser]

It's not really about which idea materializes 'first', in fact I thought I'd better wait a bit and see what happens with ogre integration before starting coding all the new organization stuff; reason being, there were a lot of open questions in my mind, and if Simbad has already been working at them for two years, might as well at least learn something from his work before doing our own thing, IF it were the case that ogre doesn't suit us for some reason.
I agree MT is risky, but like with the sound, two parts of the program with a peep-hole interface between them, no shared memory at all, should be easy.

[rewpparo]

Well, I'll describe my design a bit, hope this gives you a beter idea of how to integrate in in VS, as I must say i'm totally in the dark on that subject too.
What I'll do is a graphicEngine class, probably a singleton so that it can be accessed anywhere.
it has a startEngine() Fonction that creates a window, and initialises rendering in that window. Later I'll make it possible to initialise it in different mode, like if you want to make a "load/save/options.." menu when the game starts.
it also has createPlanet(radius, material, atmosphereType....), createUnit(mesh, material, additionalData...) etc that create a graphicalPlanet, graphicalUnit etc... object containing all data related to the way the planet/unit... looks, and declaring the necessary base objects (speres, mesh...) to the engine for rendering.
then the graphicEngine class has a renderOneFrame() method that is to be called in the main loop, so the engine never loops by itself, and you can totally control the way images are displayed.
In the future I may have to add other objects, like stuff to manage GUI, of whatever.
So I hope this gives you a good idea of how it's gonna work, and hopefully of how to integrate it into VS. If you have sugestions that would make integration easier, i'm all ears !
And thaks for the head's up hellcat, it's good to hear from you on that subject

from ogre's cubemap sample :

[chuck_starchaser]

Sounds like a clean, no non-sense approach. As soon as you have it working I'll try to port my GLSL Earth demo to it. Okay, you were asking about how to represent planets. What I will need besides the one and only sphere is a square billboard bisecting the sphere, slightly larger, onto which I can display the halo. I said I managed to do the atmo halo onto the one sphere, but that was an ugly hack. If it's easy for you to throw that in would be great. For my demo I gave the sphere 256 wedges and 128 rings. Brings up the poly count but it looks really good.
That demo shot looks great; dynamic cube-maps, eh? Exactly what we need for atmo flight. Like Simbad was reading our minds...

[rewpparo]

OK, I'm working on ogre mesh import right now, once that is done, I'll make planets. Billboards are easy to with Ogre, it's a simple matter of binding existing functions. xmesh support will be for later on, first I take care of what ogre can do alone.
About xmesh, i still believe it would be a lot easier to use ogre's mesh format, as it has exporters for most modelers, and those exporters make the material scripts as well. it would definitely make artist's job a lot easier. but I guess that decision will be for alter. No rush ^^

For the planet's main body, the sphere, do you wish it to be a mesh, or some hard coded vertex data ?
If I use a mesh, you can customise it's terrain by loading a different mesh, and add a vertex program if you wish.
If I use hard coded vertex data, it required a bit more work, but you can dynamically generate details as you come closer if you wish to. And vertex programs are still aviable.
Anyways, whatever you choose, it will be easy to replace if we find out we don't like it, and the same techniques are aviable for both through material scripts, which will remain untouched by my code.

Another small issue I ran into : when you load a mesh (or any object for that matter), do you wish it to be loaded and integrated to the world when loaded, or to stay invisible until manually activated ?
An object can be fully loaded and operational, but stay out of the renderer's queue, so it will take a bit of memory, but no CPU/GPU time. A single command can put it in or out of the queue with virtually no processor cost, it's just a matter of choice : is the default full loading, or just preloading ?

[chuck_starchaser]

I know very little about meshes, myself, but I'd guess, from your description, that we want what you call "hard coded vertex data" for planets, 'cause we have to gradually vary LOD as we fly down to a landing, as well as adding noise --we can't have meshes for a whole planet down to meters-scale detail. So I'd assume we'd iterate through rows of vertexes at each frame creating triangle strips, at each frame; and sometimes inserting new vertexes between existing ones to increase detail. This will take time and effort to code, but whatever format is most forward compatible with that, is probably best.

I don't know whether the engine preloads, currently; but if it doesn't, it should, IMO.

[rewpparo]

okay, if you're thinking that far ahead, than you'd better get ready, as the best shape to make a planet that will have dynamic LOD isn't something with wedges and rings, but a cube. at least I know that much, even though I didn't go down to the material level on my last attempt at something like this. this complicates texture mapping quite a bit, and will probably take time to code.
My guess is that for teh time being, I'll just use a mesh. nice and easy to code, and we can always make a new type for advanced planets once ogre is integrated. it's just delaying the work, the only time lost is the time required to code the "loadSphereMesh" function, and that can't be any more than a couple of easy lines.

My code was a bit more recursive and "chunked" than what you say to generate LOD. it looked like a LOD tree. Each square of the initial cube is divided, and each divided square is divided also, etc... There's some control to check that LOD generation doesn't kill the framerate too much (one division per frame max). Each time you divide, verticles are updated to match the sphere shape, plus an offset that will render terrain. Anyways, when we'll come to that, I'll have a basic code running I can take as a basis.

I'm trying to make my graphicEngine class a singleton right now. I though boost could provide that, but it seems to be an experimental function, not yet included in the basic release. Anyone knows alternative libraries that could help me there ?
The alternative solution is to pass down a pointer to every single object created by the engine, I'd hate to resort to that...
EDIT ok forget the last part, I found it in.......... ogre ^^ it uses singleton templates that I can use easily. and it now works