Graphic engine and graphic technologies

rewpparo · Post by **rewpparo** » Mon Aug 15, 2005 11:20 am

I'm still hanging around if I can be of any help

v29a · Post by **v29a** » Mon Oct 03, 2005 12:12 am

any updates on this subject yet?

Post by **klauss** » Mon Oct 03, 2005 5:34 pm

I'm studying Ogre to see if I can start the migration. So, working on it, at a very early stage. Don't expect much yet, and you most certainly won't see anything in CVS until it's pretty much done (perhaps a few implementation details and a lot of content missing).

macross · Post by **macross** » Fri Oct 07, 2005 12:41 pm

Please make a branch (is there already one?) in the cvs for ogre implementation. Others like me would like to take a look at the code and contribute.

cu
Sebastian

Post by **klauss** » Fri Oct 07, 2005 4:33 pm

Nothing is likely to be available until it's somewhat ready. But if at any point it is presentable, by all means.

v29a · Post by **v29a** » Sat Oct 08, 2005 12:05 am

ok, thanks for your reply

rewpparo · Post by **rewpparo** » Fri Oct 14, 2005 9:33 pm

Okay, back and coding ! i'm now a fully qualified ingeneer (congratulations ! thanks

), back home and ready to code !
I experimented a bit with Ogre during the second part of my trip, where I had my computer, but no internet. I got the splashscreens working, and even make a little spaceship game of my own to test out ogre's functionalities in regards to VS's specifics. There seems to be issues with long distances, mainly related to lighting and stuff, I'm still working on this. I managed to include sphere colisions using ODE (will work on triimesh soon), and the best part is that the engine should fully portable linux/win (didn't actually test linux, but I only used very standard code), and generic enough to be at least helpfull for VS. I didn't design it with VS specifics in mind though.

So what have ou been doing Klauss ? what exactly do you have, and is there anything I can help with ?

Post by **chuck_starchaser** » Fri Oct 14, 2005 10:03 pm

Welcome back, newpparo! And congratulations!
Yeah, the Ogre effort wasn't at all the same without your help, I guess

I have qualified good news. I got a new computer, 2 200 gig drives, one for windooze, one for linux. I'm all set up now, WinXP and VC7 on one side, and Fedora Core 4 on the other. So, this time I might be able to lend a hand. I say "qualified good news" because I know next to nothing about the VS engine, and nothing at all about Ogre; --I'm trying to code an autopilot for VS, partly as a way to get my feet wet with the engine; I had the code written already, just needing to get plugged in, so I thought it'd be easy...-- but anyhow, if there's boring stuff to do you'd like to offload, or better yet, classes that need to be designed, just say so. I'm not quick at figuring out libraries or other people's codes; but I can come up with good classes, properly named attributes, template patterns, you name it. And I did some shader coding too.
Klauss is usually around the forum in the daytime.

Post by **klauss** » Mon Oct 17, 2005 5:39 pm

Actually, rewpparo, I've only been studying ogre, building samples, touching them, and stuff.

I wanted to get acquainted before messing with VS.

As I posted in another topic, if you can send me your stuff at klaussfreire at gmail com it would be great, to further my knowledge.

Basically, I was thinking, since Ogre has it all pretty well structured, we could simply replace the Mesh class in VS with an ogre Entity or EntitySet. Or perhaps its own SceneNode, but I'm not sure, since we already handle that in the physics code. I'm not sure about adding a whole new abstraction layer on top (ie, another classing system), mainly because Ogre already supports subentities.

Also, that way, the transition would be very easy: just replace the Meshes with Entities, load them appropriately, etc... it's all the other ogre setup code that I'm trying to get used to, like configuration and stuff, and also I'm not sure if that much simplicity will be a problem if we later on try to do some more complex stuff.

The distances problem is somewhat fixed by making units go in two layers: z-far, and z-near. Whenever a unit is near the camera, before drawing, it's disabled from the z-far and enabled in the z-near. Whenever units get far enough, they're enabled in z-far, and disabled in z-near. In z-far we would have only big entities, not small ones. So, only big (huge) ships, stations and planets would go in z-far, minimizing duplication overhead. That's done with Ogre's layers (can't remember the name). Ah... render queues.

Actually, my current doubt is with input. I'm not sure Ogre and SDL can coexist peacefully. I know Ogre itself may use SDL as input, but it may not. To avoid recoding everything (and because Ogre doesn't seem to have joystick support), I was pondering not using Ogre's input capapbilities, and use the SDL directly. My problem is with the window: keyboard and mouse input needs a window. So... if Ogre decides to create a window with something other than the SDL... will the SDL work still? Doubtful. Also... what about MacOSX? I think we can't get around that without using Ogre's input classes... but if we do it... where's the joystick? That's my problem currently.

So... I would like to take a look at your work... could I?

Post by **chuck_starchaser** » Mon Oct 17, 2005 10:50 pm

klauss wrote:My problem is with the window: keyboard and mouse input needs a window. So... if Ogre decides to create a window with something other than the SDL... will the SDL work still? Doubtful. Also... what about MacOSX? I think we can't get around that without using Ogre's input classes... but if we do it... where's the joystick?

I just read this:

"One major problem is that [ogre demos] rely on Ogre limited internal input handling, which, according to Sinbad, will be separated entirely (if not removed completely) from Ogre in 1.1."

from http://www.ogre3d.org/wiki/index.php/Pr ... Foundation

Post by **hellcatv** » Tue Oct 18, 2005 4:35 am

on most OS's joystick input is handled separately from the window (i.e. joystick state does not depend on current window focus like mouse state does)

in linux it's all from /dev/js0
in windows it's from the directinput

we could just write joystick libs (SDL can be initialized to ONLY do joysticks without a window--in fact that's how we do joystick when a linux or windows user chooses glut I think)

rewpparo · Post by **rewpparo** » Tue Oct 18, 2005 10:37 am

Here's a 30Mb Package of my work. It uses CEGUI and Ogre for graphics, ODE for physics. make sure you rreview dependencies path, as it's specific to my computer.
[EDIT] LInk broken[/EDIT]
It only has a MSVC 7 project, no linux makefile, but it should compile fine under linux, and maybe MAC OS.
It still follows the graphicUnit, physicUnit and stuff that I've described before. And I believe it's quite fun to play with !
interesting classes are GraphicEngine and GraphicUnit. You may also want to have a look at CEGUI input injector for GUI.

As for your input problem, Ogre should be flexible enough to allow you to use SDL. If it's only a problem of getting a window handle, or whatever information you may need to initialise SDL, Ogre must be providing you with it. Just gotta find where to ask. I'll have a look into this. I don't think we should rely on Ogre's input manager.

Post by **www2** » Tue Oct 18, 2005 11:41 am

@rewpparo
Package is broking by my...

Post by **dandandaman** » Tue Oct 18, 2005 12:55 pm

klauss wrote:So... if Ogre decides to create a window with something other than the SDL... will the SDL work still? Doubtful. Also... what about MacOSX?

SDL is perfectly fine on OSX these days, so no problem there anymore.

Dan.a

Post by **klauss** » Tue Oct 18, 2005 3:49 pm

So...
...if I get this correctly, rewrite keyboard and mouse input, but leave joystick as is?

Could work.

rewpparo · Post by **rewpparo** » Wed Oct 19, 2005 7:52 am

Geez I was sure I edited my last message.. The package just won't upload, I seem to have trouble with my host.. Unitl I solve this, you can contact me via MSN loursmathurin at hotmail dot com. I'll try to find another way.

I found your solution for SDL : http://www.ogre3d.org/wiki/index.php/Using_SDL_Input
Apparently the problem only exists under windows, and there is a way to get the window handle from Ofre using RenderWindow::getCustomAttribute("HWND", &hWnd). Then you can set an environment variable SDL_WINDOWID to &hWnd to tell SDL to use that window.
Ogre's input manager is only supposed to be used for basic apps. it's not designed to be robust or anything, and I wouldn't use it in a big application.

Post by **klauss** » Wed Oct 19, 2005 2:47 pm

I don't use MSN. By principle.

But the SDL thing you found... does help. Great, thanks.
I had thought of that, just didn't know about the SDL_WINDOWID thing.

Just mail the zip file to klaussfreire at gmail. It's the best option, I think.

scheherazade · Post by **scheherazade** » Mon Oct 31, 2005 5:36 pm

chuck_starchaser wrote:Your planet thing sounds interesting. Shehrazade here is working on just that very idea, and I'm not sure how far he's got with it. Frankly I'm not sure the z-buffer problem is the toughest one. I think the toughest one is precision of representation. If you represent a planet using floats, and place the center of coordinates at its center of gravity, the best case precision you get at the surface is about 2 feet. One can certainly have local coordinate system representations, but then the bigger problem comes in: Where do you place the (0,0,0) origin for the "world". If you place it somewhere in space, by the time you get to the ground, precision is back to the range of feet. The only solution, IMO, is to have the world coordinates centered and continuously tracking the camera.
So that's my *ultimate* question: Can Ogre be modified to do that?

what I started on a while back wasn't a real engine modification.
it was just an on-demand 3d mesh and texture UV coordinate generator.
you gave a normalized-to-planet-radius vector of your space ship position relative to the planet, and it gave you back the geometry (with uv coordinates) for that planet, at some level of detail.

it would only make the visible area, and when your horizon ran out of geometry, it would regenerate the model.

it was only meant to provide a detailed model for getting close to the planet, not for actual landing on, or whatever.

if i did it today, i would do it in a separate thread.
you can keep using the old model until a separate thread finishes making the new one.

in general, I think we could really make use of multithreading in VS.
so long as traffic is one-way, there are no problems with multithreading (no write contention).

for example, you can give an AI thread data on one end, and on the other end it writes out the result of a decision.

each unit can have a thinker thread dedicated to it...

or really, since you can call thread functions like regular functions, you could for some systems call AI in your loop, and for others (with multiple cpu's) you could spawn off a thread and then just check in on it.

although, you only really benefit from having CPU's-count threads.
for a dual core single chip, going over 2 threads gives no performance boost.

the benefit would be only in doing offline tasks, like dynamically calculating the fracture and dissintegration of a mesh, but in a way that corresponds to the type and location of damage.

let the ship burn in flames until it's ready to explode in some particular way

-scheherazade

rewpparo · Post by **rewpparo** » Wed Nov 09, 2005 2:43 am

I have Ogre and SDL working together without a glitch in a sample, including keyboard, mouse, joystick, and sound support. I'm still working on buffered input support (SDL event management) , but I got unbuffered input (SDL_GetKeyState and such) woking perfectly, so I don't anticipate any problems for event handling. Code sniplets are aviable on demand

etheral walker · Post by **etheral walker** » Thu Nov 10, 2005 10:36 am

Can you post a quick list of what we can expect from the new engine? As ever with me, I mainly speak about what artists need to know when cretaing meshes and textures

Zeog · Post by **Zeog** » Thu Nov 10, 2005 1:29 pm

I complied such a quick list as an artists' reference in the wiki: http://vegastrike.sourceforge.net/wiki/Development:Ogre

rewpparo · Post by **rewpparo** » Fri Nov 11, 2005 12:10 am

Changes for artists... not that many actually. ogre wil mainly give you more options that you can use to create cool contents.
You can still model using you good old modeler, ogre supports more modelers than VS currently does.
The main change will be material scripts, but then again it is usually supported by the exporters that will generate those scripts automatically.
if you want more info about those scripts : Ogre's manual, script section
http://www.ogre3d.org/docs/manual/manual_14.html#SEC23

Post by **klauss** » Fri Nov 11, 2005 12:15 am

About automatically generating scripts, I've created a template and template instancing system which will make that much easier... so it's officiel: artists need not create their own material shaders/scripts, but they can if they want or need it.

Post by **hellcatv** » Sun Nov 13, 2005 4:46 am

nice klauss--how close is this to actually working--or are you just working at mesher converters

please *please* klauss commit what you're doing--- I'd hate to see your h/d fail like it did for one of our other developers causing him to lose all his changes... doesn't matter where you commit--even if it just saves a bit of time--- long as you make a fork then you don't have to worry about merging and it's all upstream... can you possibly go ahead and do that?

also lets us toy with what you've done lol

Post by **klauss** » Mon Nov 14, 2005 3:30 pm

Kay, I'll commit the new mesher (mostly what I've been working on) and the test app (one of Ogre demos quite modified).
When I have the game framework at least all outlined, I'll commit that. Nothing in that framework will work, though... I'm just creating abstract classes to sort things out.