Ideas / Feedback for an AdvancedOgreFramework

[spacegaier]

Hello toghether,

due to the positive feedback on my Basic Ogre Framework, I'm currently thinking about making a sequel, called Advanced Ogre Framework, based on the previous one.

So far I added the following things:

• GameStates (based on the implementations of the wiki, but modified a bit)
• CEGUI menus
• DotScene file loading

The aim is rather the same as with the first part: An application that combines many basic (and now also some more advanced) topics in one single appplication to show relatively new users how to bring the things learned in the Ogre tutorials toghether. So it should fill the gap between the tutorials and the really advanced and specialized stuff in one out-of-the-box-running program.

Therefore, I'd like some comments from you on this idea in general and proposals what features could be added too, that are needed for almost every advanced application.

Looking forward to hear from you
spacegaier

[jacmoe]

Picking. Object selection. Dynamic materials (highlight on selection).
Scene reloading.


<edit>
Buffered/Unbuffered input mode switching.
</edit>

[spacegaier]

Picking / Object selection is a really good idea! But what do you mean by dynamic materials? Do you mean setting e.g. the red component in the diffuse color of the selected object to a higher value or change the material when beeing selected to another one, defined in a scirpt?

Concerning the buffered / unbuffered input switch: I already do use both somehow in the framework: I use the buffered part of OIS for key presses (for e.g. changing render mode or toggling the overlays) and have a custom input function for getting the unbuffered (without OIS), called every frame.
-> I don't really get your point here. Could you explain it a bit more, please.

[jacmoe]

It's a small change:

Code: Select all

void BaseApplication::switchMouseMode()
{
	mUseBufferedInputMouse = !mUseBufferedInputMouse;
	mMouse->setBuffered(mUseBufferedInputMouse);
}

You will need it when you go CEGUI.
In Morrowind you entered GUI mode by pressing the spacebar..

Object highlighting: yes, in code.

[ShadowFire]

I second the asset reloading stuff. I would love to see example of reloading a shader at run-time and re-applying the parameters.

[spacegaier]

I don't plan to use a shader for this, but a simple material with ambient, diffuse, specular, and emessive values and change them and perhaps the alpha.

@jacmoe: Still not sure about this switching between the input modes. Don't know why and where I should need this. Could you enlighten me, please .

[Tony Richards]

A good example of buffered vs unbuffered is switching between a WASD input for moving your character around, and then pressing the slash (/) key to switch to the chat window where you want to enter some text (via buffered mode). When you press the ENTER key, it switches back to unbuffered where you can use WASD to move your character again.

[spacegaier]

But why making different modes out of it, when you can have both at a time? Move your character around with WASD or hit a key for e.g. opening the chat window without having to toggle some input mode.

[Tony Richards]

So you can't use WASD in your chat window?

eh, and I just noticed jacmoe was talking about mouse not keyboard... I'll let him speak for himself

It'll be a whole lot more clear once you start integrating with CEGUI. Under certain modes, you're going to want to intercept some (or all) of the keys, but under other modes you're going to want to pass them to CEGUI. Same goes for mouse input.

[jacmoe]

You need to toggle input mode, because you need a mouse pointer, and because you need to react to keyboard input in a different manner when entering text into a console, moving a window around on the screen, or selecting something in the screen.
A different mode from using WASD keys for movement and mouse for looking around.

<edit>Tony sneaked in before me - I am indeed talking about both mouse and keyboard</edit>

[spacegaier]

Right, my solution doesn't cover typing anything in the chat function, just fireing it up. Never thought about different modes for the mouse though.

Will go on working on this once my exams are over (still 6 exams in the next 8 days, week-end exluded ).

[jacmoe]

Right, my solution doesn't cover typing anything in the chat function, just fireing it up.

That sounds like a one-sided chat to me.
Good luck with the exams.

[DanielSefton]

I use an input priority system which disables/enables sets of input. For example, if you move your mouse and click on a GUI element, the lower priority input (i.e. character movement) is disabled. Much better than pressing a key to enable GUI.

[CABAListic]

That all sounds awfully complicated to me. My stance is that whatever input the GUI system can consume, it should consume. Any input I get I first offer to CEGUI, and CEGUI returns whether it processed the input or not. If it did, I'm done, if not, I use the input for whatever else there may be, including camera movement etc.. After all, the GUI is the immediate visual place of interaction with the user and should take priority.
This also allows me to have handling of a chat window completely contained inside the GUI code. The GUI would process a hotkey to open the chat window, once it does, the chat window's input line will have focus and therefore CEGUI can process any character input, including w,a,s,d. Once the chat window is closed again, CEGUI will let wasd pass, and I can have them processed by my camera controller.

Or put another way: GUI systems should already have a means of dealing with focus (i. e. the active element upon which input has to act), so why should I care?

[spacegaier]

Okay, I worked a little bit on it today:
- fixed crahses when switching the CEGUI layouts for the different states
- implemented object selection
- implemented highlightning of the currently selected object

And that is where I need your help again:
I have one object loaded (the Ogre head). If you click on it, its skin color is manually (= in code) changed to red. So but what should I do when you deselect him (by clicking in the middle of nowhere)?
Should I clone the original material and reapply it? Should I randomly apply another color? I also thought about implementing reloading of materials, but I think that's too much for an advanced version (maybe for the pro version, but therefore I first need to become one and that will still last for a long time...).

Any cool ideas on this?

[Crazy_Yellow_Rabbit]

- implement object selection is a nice idea for noobs

Do you think an audio integration (OpenAl) could be done ? like a sound played when you click on the Ogre head.

[spacegaier]

Mhh..never thought about audio. Wouldn't that require additional dependencies? I already have tinyXML due to the DotSceneLoader.

I'm also not sure whether it won't be too complex / too much to understand.

But let's hear what the rest thinks about it...

[jacmoe]

Audio is a bad idea, IMO. Let's keep it Ogre only.

About the material: get a pointer to the old material, clone it, use the new material, and set it back to the old one when highlighting is over.

[spacegaier]

Okay, so both things as I thought .

I've just seen, you proposed scene reloading? That means loading a scene via DotScene, alter it at runtime (move some parts around whatsoever) and then reload the original state, right?

[jacmoe]

It doesn't have to be dotscene, but people ask a lot how they can clear a scene and load a new one.

[spacegaier]

Okay, I'm finally back on working on this topic (at least a bit ).

Implemented the object picking + highlighning via different materials now. However there are two points that need some clarification / ideas:

1. Buffered / Unbuffered input: Any ideas how to nicely demonstrate the effect of that? Should I add a CEGUI input box on the screen and when hitting a special key, this box gets the focus and the input mode is switched so that you can directly type in some text?

2. Scene reloading: Are we now speaking of just resetting the stuff from the DotScene (so mainly the position of the objects) or of a complete Ogre Scene / material reload?

Apart from these two things, any points open that haven't been implemented and should find their way into this application?

EDIT: I will also put in a SceneQueryMask so that the objects loaded from DotScene (three cubes) won't be selectable (as the material code would lead to a crash with them, due to them not having a submesh with the index of 1).

[spacegaier]

Any input / opinions / tips?

[boyamer]

so hows development going?
Any release'?

[spacegaier]

Yes, QueryMasks are in .

Not more than mentioned here in the thread. I will try to get it finished the next days. If not, I'm considering releasing a pre-version with the most of the planned features in.

[mkultra333]

I'm building my project on top of your original OgreFramework. Since this is to be a generic framework, I'll ignore things like shadow code and stuff, but looking back one thing I had to add was a generic file loader. I called it "RawFileManager" and it's basically http://www.ogre3d.org/wiki/index.php/Ad ... Tutorial_1 modified to load any kind of file and give a pointer to it.

This would have been handy for me, might be useful for others since you never know what kind of file they might want to load.