Ogre interface framework

Development directions, tasks, and features being actively implemented or pursued by the development team.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Post by klauss »

etheral walker wrote:do you have some screens before I grab it with my 56k modem?
Finally. It did take long, didn't it? Sorry, there's quite a lot going on in RL...

Screenshots are back... new ones... in here

There's this one in particular that I find interesting... not particularly good looking, but take a look at the polycount :shock:
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
MamiyaOtaru
Privateer
Posts: 729
Joined: Tue Jan 07, 2003 8:32 am

Post by MamiyaOtaru »

Klass, I can provide you with a bump map for the tarsus, and a base texture that doesn't have the bumpmapping baked in. I'd be curious how that would look. Is bump mapping ready to go yet?
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Post by klauss »

@mamiya: No, but yes. Meaning: I can write a normal-mapped 2.0 shader in a sec, and use it without even rebuilding. The same shader for 1.4 and the fixed pipeline (possible, it's in Ogre's samples), would take some prior adaptation work, though.
So... do send them, to klaussfreire at gmail... if possible, if you have the model for the tarsus with proper normals I'd appreciate it as well... old versions of mesher killed smoothing groups, and that's one of the things making it look less-than-nice (see... the mining base has smoothing fixed, and looks much better).
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
hurleybird
Elite
Elite
Posts: 1671
Joined: Fri Jan 03, 2003 12:46 am
Location: Earth, Sol system.
Contact:

Post by hurleybird »

Looks heavily compresses, and the planet and background textures where low-res, but the ships and stations looked beautifull.

Also, the planet shader demo was awesome. The variaty of moods that you were able to create was very impressive.

Great work klauss!
KorJax
Merchant
Merchant
Posts: 47
Joined: Mon Aug 22, 2005 10:28 pm

Post by KorJax »

Amazing! Finally, ive seen the Ogre SS 8)

Although I'm alittle worried with your "interesting" screenshot as far as FPS goes, how good is your computer?

Is there any sort of LOD system avalable in place (or will be avalable)? I am assumeing thats the uber low FPS cause in that SS, or it could just be the fact that the ship on the right is uber detailed and huge (hope we can turn that down for us low-end PC users :lol: )
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Post by klauss »

@hurleybird: heavily compressed? I'm not sure I follow...
@KorJax: I'm using a P3 1Gz, 512MB RAM, ATI Radeon 9800 (w/256MB VRAM). But the ultra-high polycount is because units are not being distance-culled (not drawn when they're too far). That's very simple to do... I just didn't do it to see how it worked.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
hurleybird
Elite
Elite
Posts: 1671
Joined: Fri Jan 03, 2003 12:46 am
Location: Earth, Sol system.
Contact:

Post by hurleybird »

Klauss: Heavily compressed as in .jpeg compression of the actual picture, nothing engine related :D
rewpparo
Hunter
Hunter
Posts: 83
Joined: Sat Jun 11, 2005 8:11 pm
Location: Rouen, france

Post by rewpparo »

Wao those look real nice ! Great job guys ! Is it integrated in VS yet or just a framework ? were the screenshots done in debug or realease ?
If you publish In game screenshots on the ogre forum, you'll certainly end up in the Ogre galery, and maybe even get a front page !
Looks really stunning !

Did you get Z buffer precision issues ? How did you solve them ?
There are 10 types of people in this forum
Those who understand binary... and those who don't
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Post by klauss »

@hurleybird: ah, yes... I compressed it quite much because they were meant for ethereal, who's using a narrow band.

@rewpparo: Just a framework. Every time someone asks that I feel the pressure ;) - I will integrate it with VS very easily once the framework is finished, since I'm designing it just to that end.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
hellcatv
Developer
Developer
Posts: 3980
Joined: Fri Jan 03, 2003 4:53 am
Location: Stanford, CA
Contact:

Post by hellcatv »

cool klauss

from what I've seen there are still z-buffer problems with the planets themselves being at zfar (and hence all interfering with each other)
but I'm not entirely sure---it looks like after klauss gets the camera code to center the rendering at the camera instead of the center of the universe it will be better--but he might need to turn off zbuffering for planets altogether (and fake a transparency bit so they render in order)
Vega Strike Lead Developer
http://vegastrike.sourceforge.net/
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Post by klauss »

hellcatv wrote:---it looks like after klauss gets the camera code to center the rendering at the camera instead of the center of the universe it will be better--but he might need to turn off zbuffering for planets altogether (and fake a transparency bit so they render in order)
I don't think I'll have to turn off z-buffering.
After that part of the code kicks in, the combined z-buffer precision will be around 56 bits-worth. That's a lot, enough to make planets draw properly, I think.
But... we'll know for sure soon.

Even if that fails, I can make the z-far queue adjust its precision dynamically. I'm determined to make possible z-buffered rendering of planets.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Klauss, I downloaded data5.x and tried the explorer; I'm not sure what I have to do to get working on shaders, tho, like how to place a planet in the explorer scene, how to move around in explorer, and what to do to work in glsl, if that's possible. Also, no idea how I get this this stuff setup under Visual Studio.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Post by klauss »

To move around: pressing tab will take you from one place to other. Pressing 'u' will add a random unit. Not much more you can do. If you want a specific unit, what I do, is mess up with units_vega.csv (create a backup, name the backup bak_units_vega.csv - otherwise the explorer will still load it - and delete every other unit from units_vega.csv).

To work with shaders. Basically, read Ogre's manual, the section about materials and shaders, for how to set up .material and .program scripts. Take the ones in core/shaders and core/materials as an example. Notice, though, that there are no (well... just one) .material files, they're all .materialTemplate. The difference should be obvious.

Don't worry much about getting the material templates right. Once you have a working draft, I can fix them - they're tricky bastards... useful once you get them right, but until you do so...

About setting up the explorer on Visual Studio... well, in module vega-proj you have some code and a Visual Studio 6 project. You can import it with VC Express, but setting up all the dependencies is a pain - I tried already. Succeeded... but after long hours. Microsoft doesn't make your life easy with Express. Rather, it makes it harder - make sure you set up all include/lib directories for the Platform SDK, DirectX SDK, .NET Framework 2.0, and the dependencies (including Ogre, zziplib, zlib, devil, Cg, and who knows what else). I think you can skip zziplib, zlib and Cg if you don't intend to build Ogre itself.

Anyway... I'm still using VC6 because VC Express has a nasty memory leak, a tad difficult to fix (MS instructs us users to rebuild MSVCRT80.DLL - not fun, mostly because of the havoc it wreaks on XP machines, because of manifests - luckily I don't use XP). I'm still waiting for a proper fix (basically, a new MSVCRT80.DLL from Microsoft).

Any other problem, just mail or PM me, and I'll try to walk you through it.

EDIT: Personally, I prefer RenderMonkey to prototype shaders. It's not perfect, but it's quick.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Ok, I'll email you with questions, once I figure out what the questions are... :-/
balloyd1
Trader
Trader
Posts: 17
Joined: Wed Aug 24, 2005 4:42 am

IO Modification in line with Ogre update

Post by balloyd1 »

I've been working on a replacement Input system and a new setup (in-game!) window. Since we are going to start requiring OGRE for rendering, I would like to rework the current renderer to remove GLUT and just use SDL. The winsys subsystem would have input handling removed from it and input would be handled in the input handlers (makes, sense, no?).
I should be able to get things to run better by doing the SDL polling for events in the location where the input handling is done now. When the renderer is replaced with OGRE, then SDL Windowing could stop being used and SDL be used for input only. SDL and OGRE work together pretty well.

So any comments about simplifying things so that SDL is the way inputs are handled for now? I don't know of any systems we are still supporting that do not have an SDL port.
Halleck
Elite
Elite
Posts: 1832
Joined: Sat Jan 15, 2005 10:21 pm
Location: State of Denial
Contact:

Post by Halleck »

Sounds good. The less we use pure SDL for graphics, the better (there are some known problems with SDL graphics and Mac OS.)
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Post by klauss »

Hm...
...don't forget I was reworking GUI systems as well.

That means that I'm designing input handling too. Well... I would, I just didn't get to it yet.

The idea is to have both raw input, and preprocessed input. Preprocessed input would be like specific commands: "turn right" - "activate ECM"... bound keys, more or less.

Raw input would be keystrokes themselves...

For that, I was planning on adding a few abstraction layers:

1) Input source plugins - you register them with the main UserInterface framework, and they can provide buffered or polled input - no polling, please, if avoidable - that means: no polling for keyboard and mouse.
2) Input processor plugins - you register an input processor, that takes the raw input from the active sources, and maps them to abstract commands. They basically work like input handlers (next) that either generate new commands out of what they receive, or filter out the received command stream to produce their preprocessed streams. Examples would be joystick calibration modules, context-sensitive splitters (sometimes you want 'j' mean 'jump', but some other times, you want it to mean 'type the letter J').
3) Input handlers - command targets... listeners... whatever. They receive preprocessed commands.

Now... I didn't code any of that yet.
Your system would be... I gues... a plugin suite (of course... builtin plugins) - you would provide an SDL Joystick input source, an SDL keyboard input source, and an SDL mouse input source. You would also provide some processors (Joystick-to-Flighstick processor, with calibration and stuff, also a Mosue-to-flightstick for the different flight modes, etc...)

But you would need a working interface where to plug in your code... sorry, but I don't yet have such an interface.

About the editor, I would code the editor as a python base screen, actually, that manipulates configuration settings, given the increased flexibility of the CEGUI interface.

Again... it all depends on the work I'm currently doing. We should coordinate. I'm working on my next iteration of the Ogre framework, and it will include a minimally functional GUI framework - without, for now, CEGUI layers - those will be included later as plugins.

From that release, you'll have solid ground on which to stand, I think. But since you're already working on input, it would be wise to coordinate so that my design fits your implementation as nice as possible.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
balloyd1
Trader
Trader
Posts: 17
Joined: Wed Aug 24, 2005 4:42 am

I already have some of a framework coded.

Post by balloyd1 »

Actually, your input ideas match my coding very closely.

Here are some basics.

Code: Select all

class InputHandler
{
  private:
    static std::map<std::string /* Handler Name */, 
      InputHandler* /* Handler */> handlers;
  public:
    static std::set<std::string> getHandlerNames(std::set<std::string> &names);
    static InputHandler* getHandler(const std::string &name, const std::string &data=std::string(""));
    static InputHandler* getHandler(unsigned int player_num, const std::string &name,
      const std::string &data=std::string(""));
    static const std::string &getHandlerName(const InputHandler * const handler);
    InputHandler(unsigned int player_num, const std::string &name);
    InputHandler(const std::string &name);
    virtual ~InputHandler(void);
    std::string GetBindingID(void);
    
    // When removed or set up as a key handler, used to reset the handler.
    virtual void Reset(void)=0;
};

class InputInterface
{
  private:
    static std::set<InputInterface*> Interfaces;
  public:
    static bool ProcessAllInputs(int whichPlayer);
    static bool BindAllInputs(const std::string &mode);
    virtual bool ProcessInput(void)=0;
    virtual bool BindInputs(const std::string &mode, int whichPlayer)=0;
    InputInterface(void) {Interfaces.insert(this);}
    virtual ~InputInterface(void) {Interfaces.erase(this);}
};

One of the specialties of this class is a textinputhandler, which gives "raw" key information (actually, not the raw keys, but ascii text from the keyboard all mapped into the active text handler).
There are support for Axis and Key bindings. These do not state which key it is, but instead state what the key went to. If you bind multiple keys to a single action, there would be no telling them apart.
To improve effeciency, I was going to have it so that once a key was pressed, it would indicate the same modifier information when released as when pressed. If you press
shift alt 1 release alt release shift release 1
the alt-shift-1 press and release actions would fire when the 1 was pressed and then released.

I have new handlers (consumers) written to allow this to be placed in now. My understanding was you were working on migrating to Ogre. I did not realize you would tackle a rewrite of the input system as well. I was hoping to help with the migration by giving you the input subsystem while you focused on the graphics side of things. I've already done some work with CEGIU, and was going to use C++ and CEGUI to build a in-game setup program.

I was going to use the events framework from SDL to do the initial input system.
Instead of waiting for events all the time, I was going to let them pile up and handle them during the current keyboard handling time. If nothing's changed, it won't take much time, else it will take the same time as it would have taken to handle the event asynchronously in a seperate thread, and gets rid of a number of race conditions. Since this is called several times a second, the input queue will never get very big. And since inputs are handled right before anything could use the data in the simulation, there would be no additional perceived delay by the user.

So my input processor would have a ProcessEvents function that would be called when it was time to act on the latest inputs. The events would be queued between calls to that function.

One thing this interface system will allow is the selection of seperate bindings for different conditions. For instance, if Player one leaves the Cockpit at a dock, then the bindings could go from Cockpit bindiings to Dock bindings. This should work really, really well with things like command modules versus cockpits and turrets where the input can be tailored to what the user is doing right then. It should also be really nice if a first person perspective is added later.

This input system has the nice advantage that registering an input handler does not bind it, and registering it gives the setup system information that can be used to create a setup screen in a more generic way. It's not finished, but its closer than not started. :)
hellcatv
Developer
Developer
Posts: 3980
Joined: Fri Jan 03, 2003 4:53 am
Location: Stanford, CA
Contact:

Post by hellcatv »

I'm glad you two are coordinating---the abstraction over our current system is most well needed---especially if we want to do things like "submenus" and other features users have come to expect :-)
Vega Strike Lead Developer
http://vegastrike.sourceforge.net/
Halleck
Elite
Elite
Posts: 1832
Joined: Sat Jan 15, 2005 10:21 pm
Location: State of Denial
Contact:

Post by Halleck »

Is the SystemExplorer binary in svn (/trunk/data5.x/bin/) supposed to work? It keeps throwing strange exceptions:

Code: Select all

...
05:00:41: Loading library ./OgrePlugins\RenderSystem_Direct3D7
05:00:41: An exception has been thrown!

-----------------------------------
Details:
-----------------------------------
Error #: 9
Function: DynLib::load
Description: Could not load dynamic library ./OgrePlugins\RenderSystem_Direct3D7.  System Error: The specified module could not be found.
. 
File: E:\Projects\OgreCVS\Branches\Azathoth_VC6_clean\ogrenew\OgreMain\src\OgreDynLib.cpp
Line: 82
Stack unwinding: <<beginning of stack>>
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Post by klauss »

I got this error from time to time.
You could try disabling the DX7 plugin from plugins.cfg, if it's a problem specific to that one. But in one system (one without any kind of acceleration), I couldn't get even OpenGL to work - not even in software emulation mode.

In general, that exception means either an error in the initialization or missing dlls. If you have the dependency viewer (depends), then you could see if there's any dll missing.

In any case... yes, it's supposed to work, even if it's quite outdated (even out of synch with the source in SVN). When I get to my target (having the GUI framework minimally functional), I'll commit both code updates and binary updates. In the meanwhile... try leaving only DX9 or OpenGL in plugins.cfg, and see if that helps.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
Halleck
Elite
Elite
Posts: 1832
Joined: Sat Jan 15, 2005 10:21 pm
Location: State of Denial
Contact:

Post by Halleck »

Sorry, no dice. I guess I'll just have to wait until that next commit.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Post by klauss »

Hm... I'll see if I can put together a commitable version earlier.
I've already played around with that error, while trying to get it to work without hardware support (a lost cause, but I was curious), and many things got fixed. Still not working without hardware support, but it could work for you. So... again, I'll see if I can commit an up-to-date version before "reaching the target", so if it doesn't work, I can organize a bughunting session with some more useful information.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
Halleck
Elite
Elite
Posts: 1832
Joined: Sat Jan 15, 2005 10:21 pm
Location: State of Denial
Contact:

Post by Halleck »

Sounds good. Please announce it in this thread when you do.
www2
Venturer
Venturer
Posts: 537
Joined: Sat May 14, 2005 10:51 am
Location: milkyway->the sol system->earth->Europe->The Nederland->Soud Holland->Leiden
Contact:

Post by www2 »

Ther ar a new version of orge for download @ www.ogre3d.org...
Is this a good idea for the nex release or for 0.5.5 release?
All Your Base Are Belong To Us
Post Reply