Graphic engine and graphic technologies

Post by **chuck_starchaser** » Wed Jun 22, 2005 4:06 am

I think charlieg is right. I feel a great deal of laziness about pouring a week or two investigating Ogre, but on the other hand, it could save us months of work, which we could spend on things more VS-specific.

If we incorporated Ogre now, as the back-end rendering stage, we could spare ourselves the time it will take to design, code and debug:

1) Materials management, including fragment shaders
2) (Maybe) new bfxm format including vertex shaders
3) Shader program management
4) HDR

Plus, it would ease the integration of other features needed for planet-side walking, such as shadows, dynamic cube-maps, octrees, clothes, skeletal animation, muscles, ragdoll physics, water physics, etc.
Plus we get features we can use anywhere right now, like particle systems, explosions and what not.

Then we can take all this extra time and pour it into:

1) Menu driven interfaces to replace keybindings/key contextualization, and other interface features such as new HUD, free head turning, sound...
2) Improved dialogue in space, ability to ask questions, speech synthesis
3) RPG type features, such as npc's that 'join your quest', personal inventory, knowledge representation, PDA, etc.
4) Strategy: A way of 'programming' npc team-mates, drawing plans, setting priorities, smart weapons player customizable through a python programming interface in the game.
5) Ship design and specialization, greater weapon variety, eg. railguns, stand-off weapons, stealth, ECM and visual 'cloaking' systems
6) Genetic algorithm to improve npc ai throughout the game, npc's that follow routes, trade realistically
7) Complex but intuitive handling of faction sympathies, and geographical distribution of difficulty

Better planets, space elevators, better random system generator
9) Atmospheric braking, entry, flight and landing
10) Exploration, colonization, planet-side construction, realistic economics, business and planet management
11) Multiplayer, in-game arcades, socialization, networking, ship synchronization to facilitate escort missions and team and convoy flying.
xx) Etceteras....

We should at least take a good look at this option rather than dismiss it based on subjective feelings about the whole idea of "merging with foreign material". That's how evolution really took off

Post by **hurleybird** » Wed Jun 22, 2005 5:18 am

This is slightly OT but another thing a seperate graphics engine would save time for would be multi-thread support. A game like VS can have a lot going on in the back end, and multiple threads could greatly improve aspects of the dynamic universe.

Post by **klauss** » Wed Jun 22, 2005 4:09 pm

No engine replacement can save you from the intrincacies of multithreading. Believe me, I've done multithreading. If you don't crash against the GPU's wall, you'll trip on your own feet. If you don't, you'll trip on someone else's feet.
No... multithreading is a tricky issue, better done calmly and consciously, never taking anything for granted. Like Ogre, if you get slappy because "Ogre is Thread Safe", you'll soon have broken the entire project due to uncountable and untrackable thread-safety mistakes. And not because Ogre isn't thread safe, perhaps it is, but your usage of it is not.

pifactorial · Post by **pifactorial** » Wed Jun 22, 2005 6:38 pm

chuck_starchaser wrote:...skeletal animation, muscles, ragdoll physics, water physics...

If I understand correctly, Ogre doesn't have any physics - it's for rendering, and rendering only.

Post by **chuck_starchaser** » Wed Jun 22, 2005 8:07 pm

It does have water physics, AFAIK, but what you say is generally true, although there are open source engines out there which use Ogre for rendering, so I was making a bit of leap there. When it comes to it we'd have to either emulate what some of those engines are doing, or copy it, or subsume them... whatever

rewpparo · Post by **rewpparo** » Wed Jun 22, 2005 8:33 pm

Just to confirm, no Ogre doesn't have any physics. There is only water waves for demo purposes, and BSP collision because it's too close to the graphic part of BSP, and one can't go without the other.

Post by **chuck_starchaser** » Wed Jun 22, 2005 8:38 pm

Okay, allright; I'm still going to take a good look at Ogre next week for whatever good it may be as a rendering back-end. I got the ogre plugin installed for Dev C++, but I'm not sure what to do with it... Couldn't compile the demos, but I forget now what the last problem was. Maybe it expects one is in WinXP, I'm in Win98...
EDIT: Oh, yeah, I remember now: The app crashed "illegal op" or "access violation", can't remember which, at the moment I tried to run it.

rewpparo · Post by **rewpparo** » Wed Jun 22, 2005 10:12 pm

post the error, I can help you there. compiles fine on my GCC under gentoo linux I never tried it under win98, but if you have VC++, you shouldn't have any problem.

Post by **chuck_starchaser** » Wed Jun 22, 2005 10:50 pm

I don't have VC++. It's incompatible with win98 anyways. I tried compiling Ogre in Linux and I had no end of troubles. There was a... zlib-something or other it needs. I got it compiled and installed, but ogre's configure doesn't seem to see it. So then I tried in windows with DevC++ and didn't get nowhere either. I'll try Dev C++ again to see what the exact crash message was.

Post by **hurleybird** » Wed Jun 22, 2005 11:21 pm

klauss wrote:No engine replacement can save you from the intrincacies of multithreading. Believe me, I've done multithreading. If you don't crash against the GPU's wall, you'll trip on your own feet. If you don't, you'll trip on someone else's feet.
No... multithreading is a tricky issue, better done calmly and consciously, never taking anything for granted. Like Ogre, if you get slappy because "Ogre is Thread Safe", you'll soon have broken the entire project due to uncountable and untrackable thread-safety mistakes. And not because Ogre isn't thread safe, perhaps it is, but your usage of it is not.

Actually, you misinterpreted me a bit. I said that because an engine replacement could save time that would normaly go into engine development, we could use that time to get a handle on multithreading. Now that dual core processors are out, multi-threaded games are going to get more and more common. Eventually VS will probably need to become multi-threaded, and when that time comes it there will probably be new tools/methods to make creating multi-threaded apps faster.

smbarbour · Post by **smbarbour** » Wed Jun 22, 2005 11:39 pm

Multi-threading isn't just for SMP either. You will see significant increases in performance by multi-threading.

Think of it like the stock market where your computer is a company, programs are shareholders, and threads are shares. The more shares a shareholder has, the more that shareholder has a say in the interests of the company. Likewise, the more threads a program has, the more CPU time the program will receive. Extra CPUs (cores) are a great bonus, but single core machines will have performance improvements as well.

With threads we could do things like generate a system as we approach the jump point. As long as the thread priority is low, there should be very little impact on the gameplay while the generation occurs.

Post by **chuck_starchaser** » Wed Jun 22, 2005 11:50 pm

That would be true of a program running on a busy server; most people know not to have heavy programs running while playing a game, so a game has 99% of the cpu to itself anyhow. But using threads is often a cleaner approach to programming parallel tasks, and even pipelined tasks. Thread safe libraries are often better designed and less buggy than non-thread-safe counterparts. And multi-threaded safety and performance considerations often force refactorings that are beneficial to encapsulation. Large chunks of memory going through mutexes is not good for mth performance, and neither is it probably a sign of good encapsulation.

@newpparo: I tried again with DevCpp, no errors compiling or linking, moved dll's and the executable to the examples as per the instructions, and this is the stdout:

Code: Select all

Registering ResourceManager for type HighLevelGpuProgram
Loading library plugins\RenderSystem_GL
OpenGL Rendering Subsystem created.
Loading library plugins\Plugin_ParticleFX
Particle Emitter Type 'Point' registered
Particle Emitter Type 'Box' registered
Particle Emitter Type 'Ellipsoid' registered
Particle Emitter Type 'Cylinder' registered
Particle Emitter Type 'Ring' registered
Particle Emitter Type 'HollowEllipsoid' registered
Particle Affector Type 'LinearForce' registered
Particle Affector Type 'ColourFader' registered
Particle Affector Type 'ColourFader2' registered
Particle Affector Type 'ColourImage' registered
Particle Affector Type 'ColourInterpolator' registered
Particle Affector Type 'Scaler' registered
Particle Affector Type 'Rotator' registered
Loading library plugins\Plugin_BSPSceneManager
Registering ResourceManager for type BspLevel
Loading library plugins\Plugin_OctreeSceneManager
TerrainSceneManager: Registered a new PageSource for type Heightmap
Loading library plugins\Plugin_CgProgramManager
*-*-* OGRE Initialising
*-*-* Version 1.0.1 (Azathoth)

That's it, and it craches with

Code: Select all

"This program has performed an illegal operation
and will be shut down.
If the problem persists, contact the program
vendor."

I'll reboot in unix and tell you exactly what I get there.

smbarbour · Post by **smbarbour** » Thu Jun 23, 2005 12:09 am

Right now, we partially have a poor-man's implementation of multi-threading. The soundserver works through some form of IPC if I'm not mistaken.

If we needed to, we could have an interface to allow processes to send information to VS.

Multi-threading would be better though.

Post by **chuck_starchaser** » Thu Jun 23, 2005 12:16 am

It will be a lot of work *when* (not if) it gets done, as when I asked Hellcat about a piece of code I wrote for klauss whether it needed to be thread safe, he said 'don't worry, nothing in VS is thread safe', paraphrasing him. But it has to be done sooner than later, and it will force a lot of quality refactoring. It will be a very positive step, for sure. One problem is portability. I used boost::threads, once, and I can attest to the fact that they work; but to use them portably you're limited to the lowest common denominator between the platforms.

Post by **chuck_starchaser** » Thu Jun 23, 2005 1:49 am

Okay, newpparo, I'm in linux now, just tried to run ./configure on ogre, and this is what I get:

Code: Select all

checking for dlopen in -ldl... yes
checking for pow in -lm... yes
checking for gzopen in -lz... yes
checking for pthread_create in -lpthread... yes
checking for snprintf... yes
checking for vsnprintf... yes
checking for cppunit-config... no
checking for Cppunit - version >= 1.9.0... checking for pkg-config... /usr/bin/pkg-config
checking for zziplib... Package zziplib was not found in the pkg-config search path.
Perhaps you should add the directory containing `zziplib.pc'
to the PKG_CONFIG_PATH environment variable
No package 'zziplib' found

configure: error: Library requirements (zziplib) not met; consider adjusting the PKG_CONFIG_PATH environment variable if your libraries are in a nonstandard prefix so pkg-config can find them.
[root@localhost ogrenew]#

I've no idea how to "adjust an environment variable" and I fear it's one of those things that might set me linux-free till Fedora Core 4 comes out

I did install zziplib, and then zziplib-devel, and it didn't help. Doesn't seem to see it.

eddit · Post by **eddit** » Thu Jun 23, 2005 2:43 am

@chuck_starchaiser

What version of GCC were you using? According to the OGRE Wiki, you have to use 3.3.1 with DevC++ as there is some issue with the availabe DevPack.

http://www.ogre3d.org/wiki/index.php/Th ... de_to_OGRE

Post by **chuck_starchaser** » Thu Jun 23, 2005 3:14 am

Indeed, that was another issue, I forgot about it; I think I have 3.5 or something more recent than what they mention doesn't work; but when I was looking for 3.3.1 I couldn't find it, or actually the server where they usually have the packages for DevC++ was not working. I should try again.

Post by **chuck_starchaser** » Thu Jun 23, 2005 8:54 am

Progress!: Somebody at the Ogre forum finally told me how to install this zziplib thing:
yum install zziplib-devel.i386

It installed like a charm, then I ran ./configure, make, make install in the ogre download folder and everything compiled, linked and install without a glitch. But then the guide says "and now you can try running the examples and enjoy", but I went into the examples' folders, and under bin, and under Debug or Release, and nothin: no executables to be found. But I try running make in those folders and make says there's nothing to be done. So where the hell are the darn samples?

rewpparo · Post by **rewpparo** » Thu Jun 23, 2005 9:22 am

Glad you made it

On my machine, examples are under ./ogrenew/Samples/Common/bin
Did you run ./bootstrap before configure ?
tutorial to compile under gcc : http://www.ogre3d.org/wiki/index.php/Th ... _3.3.2F3.4

Oh and when you get to that, the samples have to be run from console (because of the default config tool)

Post by **chuck_starchaser** » Thu Jun 23, 2005 2:31 pm

No I didn't do the ./bootstrap thing, which maybe why, when I tried the programs under samples/common/bin nothing happened...
So, I started again with ./bootstrap, and this time I used an option with configure, namely,
./configure --with-gl-support=GLX --with-platform=GLX
But make gave me errors:
"libtool: link: `nvparse.lo' is not a valid libtool object"
...followed by fatal errors, so I ran ./configure again without arguments
and now I'm sitting by the prompt at xterm,
whatching make's output scroll away...

Post by **chuck_starchaser** » Thu Jun 23, 2005 2:43 pm

DAMN! Now I get the same problem with make each time:
s1.0_inst_list.lo ps1.0_program.lo vsp1.0_impl.lo vcp1.0_impl.lo vp1.0_impl.lo -lCg -lILU -lIL -lpthread -lz -lm -ldl -L/usr/lib -lSDL -lpthread
libtool: link: `nvparse.lo' is not a valid libtool object
make[4]: *** [libnvparse.la] Error 1
make[4]: Leaving directory `/home/d/Desktop/download/Ogre3Dsrc/ogrenew/RenderSystems/GL/src/nvparse'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/d/Desktop/download/Ogre3Dsrc/ogrenew/RenderSystems/GL/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/d/Desktop/download/Ogre3Dsrc/ogrenew/RenderSystems/GL'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/d/Desktop/download/Ogre3Dsrc/ogrenew/RenderSystems'
make: *** [all-recursive] Error 1
[root@localhost ogrenew]#

Post by **klauss** » Thu Jun 23, 2005 3:37 pm

As chuck said, multithreading creates cleaner code for parallel tasks, hence easier to mantain, and finally, less buggy.

But that is assuming you didn't run on any of the numerous thread safety issues. It isn't hard not to: just be careful, follow the rules, and you're safe. But you have to think every step.

Yes, the soundserver not only runs in its own process and Music (the class) uses IPC to communicate with it. Music (the class - again) uses the simplest form of multithreading for track sequencing, with only a single bool acting as interface between threads. That's one of the simpler forms of multithreading: don't share complex structures - or pointers.

But multithreading for system loading, and such other tasks, would definitely require more sophisticated inter-thread communication. Now, you could do so with IPC, but that would waste thread potential. The whole idea of using threads is the ability to share memory. So, to do it right, you have to go walk right into the danger zone.

smbarbour · Post by **smbarbour** » Thu Jun 23, 2005 5:12 pm

chuck_starchaser wrote:I've no idea how to "adjust an environment variable" and I fear it's one of those things that might set me linux-free till Fedora Core 4 comes out

Well, I hate to break it to you, but Fedora Core 4 came out 10 days ago!

That always seems to happen when I download (and burn) the ISOs for a distro. The next day, the next version comes out. It never fails!

rewpparo · Post by **rewpparo** » Thu Jun 23, 2005 6:30 pm

Look like it's the opposite for me : I thought last week end "hey why not try fedora core ?", downloaded it and burned it. Looks like it was still hot ^^

As for your problem Chuck, I have no idea what causes it. I followed the tutorial, and it compiled fine on my gentoo. I believe your parameters for configure were superfluous, as only GLX is aviable on linux as a rendering system anyways. I only wonder why you compile as root. You only need to be root to make install. Try as user maybe it will help.

EDIT : just checking but did you download the linux tarball ? The windows one has makefiles, but they don't work under linux.
EDIT2 : according to the message you show, the problem is that it can't find a proper `nvparse.lo' during linking prcess. There must have been some errors with the creation of this file, could you post them too ?

Post by **chuck_starchaser** » Fri Jun 24, 2005 1:50 am

Well, here's what happens if I'm not root:

[d@localhost ogrenew]$ ./bootstrap
rm: cannot remove `autom4te.cache/output.0': Permission denied
rm: cannot remove `autom4te.cache/requests': Permission denied
rm: cannot remove `autom4te.cache/traces.1': Permission denied
rm: cannot remove `autom4te.cache/traces.0': Permission denied
rm: cannot remove `autom4te.cache/output.1': Permission denied

So, I'm redoing it all (as root), and I want to upload for you the output but I don't know how: Xterm doesn't let me copy, except through the middle-click mechanism, but I cannot highlight more than what I see on the screen. Is there a shell command that copies the output to a file, or a log file somewhere?

Vega Strike Forums

Graphic engine and graphic technologies

Compiling using DevC++