Modular Zone Plugin

[Shockeye]

I've developed a plugin for putting together levels for the portal/zone scenemanager (PCZSceneManager).
It focuses on building levels/maps out of prebuilt zones that you connect together.
A PCZSM editor for more arbitrary level geometry would be nicer, but would be a LOT more work.

The source code is in the Ogitor repository.

And I've made a sample application to show how to load from .ogscene into PCZSM:
MZPSampleApp.zip
Or here:
http://www.mediafire.com/?ym3yjimzj2m

The sample app also includes an .ogscene file and the necessary resources.
On its own, the plugin is useless - you need to predefine some zones. The sample app includes some simple rooms.

To make your own you need to define an XML file (with a .zone extension) similar to this:

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<zonedescription    mesh="Room3.mesh" portals="2" short="a small room" long="a 3 x 3l room with 2 portals on opposite ends of room."   >
   <portal width = "2" height="2">
         <position x="0.0" y="0.0" z="-3.0"/>
        <orientation x="0.0" y="1.0" z="0.0" w = "0.0"/>
   </portal>
   <portal width = "2" height="2">
         <position x="0.0" y="0.0" z="3.0"/>
       <orientation x="0.0" y="0.0" z="0.0" w = "1.0"/>
   </portal>
   </zonedescription>

And also provide the mesh and its associated materials etc. See the sample app for examples.

This plugin might also be useful for a tile-based level. Just use the zone file to define the connection points for your various tiles, and it will be easy to snap them together.

I hope this can be of use to others.
Its pretty basic so far, so any feedback/criticism/suggested features will be appreciated.

Here are a couple of screenshots:

Two tutorials:
Tutorial 1 - Shows how to convert a suitable mesh into a zone


Tutorial 2 - How to assemble some zones into a (very small) game level

[xadhoom]

Shockeye,

Thats an awesome plugin!

Currently downloading your file. Do I understand you right that you did not change anything to the core? Would you recommend any changes e.g. exposing proper interfaces to improve the support of a plugin like this?

Beside improving the user experience we also focus on improving the plugin interfaces. Any experience you would like to share?

xad

[Ismail TARIM]

I havent tried yet, but it looks awesome!!!

If you ever need any CORE support to make things easier and better, i can do whatever changes needed. Actually, my goal was to make the whole scene manager PCZMSM but due to lack of experience with it, i postponed this feature...

[jacmoe]

I am shocked!

This is my vision of Ogitor envisioned!

Being a big fan of editors like the Elder Scroll World Construction Set, and always wanted one powered by Ogre, I am overwhelmed by happiness now!

Seriously.

Ismail: Please don't make this core.
Remember what happened after you gobbing the Paged Geometry plugin made by Guru into Ogitor core?
Noone has heard from him since that...

(Kidding).

What's the point of a plugin interface if each and every plugin goes into the core anyway?

I like a pluggable architecture.

@Shockeye: Way to go!

[Ismail TARIM]

jacob:

I guess i am being misunderstood, what i mean is:

1 - We can add support function to core to make that plugin more efficient, if required
2 - We can turn our scene manager into PCZSM, to supply the plugin a more native environment, since currently it looks like PCZ but actually it isnt using it.
3 - We can officially support that plugin by integrating into our repository...

thats what i wanted to say, also to clarify, guru's pagemgeometry is using TreeLoader interface and actually for objects, our core support is only for grass (grassloader) and am sure guru will be back when he has time

I am as much excited about this plugin as you are, thats why i would like to help make it more efficient and more native...thats of course if shockeye wants to do so...

[Shockeye]

Thanks guys!

Do I understand you right that you did not change anything to the core?

Yes. It runs on vanilla Ogitor. (0.4.x only - as you know, the plugin interface on 0.3.x was different)

If you ever need any CORE support to make things easier and better, i can do whatever changes needed.

I would like a RegisterDockableWidget method! That floating dialog is annoying! ( Handy tip for using the dialog - always move it away from the centre of the screen! If you try to close the project with it in the middle, the modal Save Changes message box is covered and you can't reach the buttons or move my stupid dialog away! You have to try and right click the edge of the message box to get a context menu to close it.)

And if we could register a factory for PostSceneLoad updates it would be good. Thats why I use the toolbar. I need to control the opening of the dialog so that it only opens when a scene is open. Otherwise the RTT previews don't work. The Ogitor EntityWidget has the same requirement, but as it is loaded by the core, it is created at the right time.
I know I could register the editor for this, but I imagine that would only work for loading scenes that already have at least one object of this type in them, not a new empty scene.
(Of course, you may be able to point out an already existing way to do this that I haven't spotted.)

[jacmoe]

I guess i am being misunderstood, what i mean is:

Spare your breath - I said it jokingly.

And I kinda agree that maybe we could use the PCZ scenemanager internally.
We are doing our own zoned paging stuff which could be semi-automated by use of that scenemanager, so yes.

[Ismail TARIM]

ShockEye:

1 - Detecting scene load/unload (example in OgreWidget):

Code: Select all

OgitorsRoot::getSingletonPtr()->GetProperties()->getProperty("loadstate")->connect(OgitorsSignalFunction::from_method<OgreWidget, &OgreWidget::onSceneLoadStateChange>(this), mLoadConnection);

Code: Select all

void OgreWidget::onSceneLoadStateChange(const Ogitors::OgitorsPropertyBase* property, Ogre::Any value)

int state = Ogre::any_cast<int>(value);

the values for state are: LS_LOADING, LS_LOADED, LS_UNLOADED

so you can easily track the state and refresh or empty your dockwidget...

2 - I implemented a RegisterDockWidget(...) function, now cmpiling and testing if i broke something will commit soon, but the actual testing you have to do since i dont have an external dockwidget to test

Let me know if you need anything else, and if you like, we can put this under Plugins directory and give you repository access (Team Member)

[Shockeye]

Thanks for the help, I'll look into using that when I get a chance (Probably not until the end of the week)

What I've been doing is checking the scene status when the user clicks the button to refresh the widget, but with onSceneLoadStateChange I'll be able to refresh the widget whenever the status changes. (I did look through the code trying to find away to get such a notification - I must have missed that one)
(I'll still need the button until I can dock the widget, because it would be annoying to have that floating dialog open automatically every time you start Ogitor if you weren't using that plugin )

[AWM Mars]

I don't profess to understand most of what you guys 'talk' about. From what I gleaned, this is a plugin that allows you to create several rooms/locations that can be linked via proximity portals (like doors etc) that will unload the previous room/location and load the new room/location?

Will it hold the previous room/location in cache and load the new room/location ahead of time using a proximity detector?

From what I am looking at..... I see the whole room map being laid out and this plugin automatically creates the http linking between rooms. If this is correct, I can see why people are happy