|
|
|
Return to Panda Features in Development
by Gogg » Thu Oct 21, 2010 8:32 am
I've always disliked the idea of engine-generic type-specific stand-alone level editors (like the one at hand). They constrain you to a particular data model so unless you are doing a very specific genre they are useless to you. If you have a very specific terrain format or a solution for terrain paging, or you can't have scenes in monolithic files cause you stream them seamlessly, or if a part of your scene is generated procedurally, etc, etc... then the editor is useless to you.
What I would like to see instead of an editor is a series of facilities inside panda to ease the construction of an editor tailored to your needs. Like for example:
- A 3D gizmo/manipulator thingie with arrows or w/e you call that for scaling/moving/rotating. Complete with mouse collision detection on the arrows, you'd just need to attach one to a node and start manipulating away.
- A way to convert a node and all the nodes below it to JSON or XML or something standard and to recreate the tree from this data later. We'll probably be able to use COLLADA for this anyway.
- A way to attach information in the form key:value to nodes.
- Classes to generate light maps and stuff like that.
- Maybe some specific UI widgets to show the properties (key:value) of a node, only text, nothing fancy.
And a couple of things like these, plus the incoming rocket gui integration for the UI widgets if you don't feel like embedding. Then you could easily roll out your own useful editor, maybe even inside your game like Doom 3 does.
Last edited by Gogg on Thu Oct 21, 2010 8:51 am, edited 2 times in total.
-

Gogg
-
- Posts: 475
- Joined: Thu Sep 24, 2009 1:06 pm
-
by Mindblighter » Thu Oct 21, 2010 8:43 am
Interesting coincidence, I added a blueprint to Launchpad for some kind of lightmap/ambient occlusion generation recently 
-
Mindblighter
-
- Posts: 98
- Joined: Thu Aug 02, 2007 7:33 am
- Location: Finland
by Gogg » Thu Oct 21, 2010 8:45 am
Yeah I think that is the way to go, having specific features inside the engine and then having a tutorial on the manual on how to roll your own editor.
-

Gogg
-
- Posts: 475
- Joined: Thu Sep 24, 2009 1:06 pm
-
by Anon » Thu Oct 21, 2010 10:00 am
Gogg wrote:I've always disliked the idea of engine-generic type-specific stand-alone level editors (like the one at hand). They constrain you to a particular data model so unless you are doing a very specific genre they are useless to you. If you have a very specific terrain format or a solution for terrain paging, or you can't have scenes in monolithic files cause you stream them seamlessly, or if a part of your scene is generated procedurally, etc, etc... then the editor is useless to you.
For my current project it is useless for the reasons above.
But what about all the other cases?
For other projects Ive done this would work.
And the things above could somehow be done with user-made plugins.
So I disagree, kinda.
-
Anon
-
- Posts: 1556
- Joined: Thu Oct 29, 2009 3:07 am
by Gogg » Sat Oct 23, 2010 12:02 pm
It's impossible to have a plug-in system in an editor that fix those problems, and if you really wanted achieve one you'd have to put more thought into it than into Panda itself. If you didn't then no two plug-ins would be compatible.
There's a reason every game has its own editor, really. Every RTS game comes with it's own editor for example. Can you imagine an universal editor that would work for more than two RTS games? Impossible. Take a look at the software applications industry, we have professional applications for everything, modeling, drawing, ides, we even have applications for the most specific and silly tasks like texture wrapping or asset management, but where are the universal scene editors being used by big studios for any game? There are none. I know there are some scene editors suited to particular engines like ogre3d but they could only be used for incredibly boring concepts.
In fact it wouldn't work with almost any genre.
RTS? Nop.
Graphics adventure (extinct)? Nop.
Arcade? Nop.
Sport simulation? Nop.
MMO? Nop.
So that only leaves us with load-per-level 3d scenario games. But it still doesn't work for most of them unless they are very small. For example if your game is multiplayer you are gonna want to have a BSP and visibility zones because you don't want maphacks to be possible. This would need to be integral part of the editor and suited to your needs. Just an example, there are a million reasons you need your own formats when you have a complex game. The most important being that the loadable levels model is obsolete and now you want things to be seamless, doing a generic editor at this point is like embracing the 90's. You now want to design game experiences around your networking infrastructure. Also scenarios need to be dynamic which means procedural content, which is incompatible with a generic editor, plug-ins or not because in order to have an editor you need to have some assumptions about some things that you may want to generate procedurally. This would be a piece of cake if instead of an editor you'd have a series of facilities to roll your own. But the other way around, generic editor with plug-ins it's impossible, or it would have been done by now.
-

Gogg
-
- Posts: 475
- Joined: Thu Sep 24, 2009 1:06 pm
-
by teedee » Sat Oct 23, 2010 6:04 pm
The only way I see it as viable would be to develop an editor hand-in-hand with basic gameplay classes, since a game's editor and the "things" it manipulates are tied so closely together. For example create a controllable character class, a collectible item class, and so on. These classes could act as a base for people to modify to suit their own needs, or to add their own game-specific classes.
Saving out Python scripts from a level editor is not the best idea, but if it saved plain text or some other generic format (XML, YAML, etc.) it would be quite easy to use that data in either a level-load or stream-loading context.
If a functional framework of an editor was created this could allow it to be expanded to work with multiple game types. It's pretty much like what you suggest but plus a working example of how to use it.
Of course I am only considering the object placement side of the task. Most games consist of a static "world", and on top of that the "stuff" placed therein. Some games combine these two things into one editor, and some have separate editors for each task.
-
teedee
-
- Posts: 782
- Joined: Tue May 12, 2009 11:33 pm
- Location: Kepler-22b
-
by Anon » Sun Oct 24, 2010 1:24 am
Meh, I dunno 
-
Anon
-
- Posts: 1556
- Joined: Thu Oct 29, 2009 3:07 am
by Elzair » Tue Oct 26, 2010 8:40 pm
Did this project ever get included in CVS?
-
Elzair
-
- Posts: 1
- Joined: Tue Oct 26, 2010 8:39 pm
by neighborlee » Sun Nov 07, 2010 6:25 pm
Anon wrote:Gogg wrote:I've always disliked the idea of engine-generic type-specific stand-alone level editors (like the one at hand). They constrain you to a particular data model so unless you are doing a very specific genre they are useless to you. If you have a very specific terrain format or a solution for terrain paging, or you can't have scenes in monolithic files cause you stream them seamlessly, or if a part of your scene is generated procedurally, etc, etc... then the editor is useless to you.
For my current project it is useless for the reasons above. But what about all the other cases? For other projects Ive done this would work. And the things above could somehow be done with user-made plugins. So I disagree, kinda.
There are plenty of individuals that may find Cmu's work useful.
If you want a example of a working decent editor for a oss game engine here is one for you:
http://www.ogitor.org/HomePage
Apparantly its working for someone.
cheers
nl
One Game at a time-
http://heartseed.sf.net
[ We are currently looking for help ]
Email us or goto: irc.freenode.net
to channel #heartseed {You can also find us in #neighbors & #panda3d }
Thank You.
-

neighborlee
-
- Posts: 149
- Joined: Sat Jun 18, 2005 11:01 am
- Location: Seattle, Washington
-
by detectedstealth » Thu Nov 25, 2010 8:37 pm
For anyone trying to run the editor you might want to try running "LevelEditorStart.py" imagine that 
-
detectedstealth
-
- Posts: 9
- Joined: Thu Nov 25, 2010 7:38 pm
-
by kurohyou » Tue Dec 14, 2010 5:41 pm
I like your idea, Gogg. It would be great to have a toolbox module with basic, abstract classes which can be used to create any editor you want. I've always though the wx module was neat in the way you could use style bits in the class constructor to get different types of widgets. Maybe we could employ a similar approach here. 
-
kurohyou
-
- Posts: 209
- Joined: Tue Jun 29, 2010 9:59 pm
-
by robsullivan » Wed Aug 15, 2012 1:08 pm
hey is anyone else getting this message
- Code: Select all
protoPaletteData doesn't exist
as soon as I get that message leveleditor it bombs out. in protoPaletteBase.py it is trying to do this: - Code: Select all
def populate(self): moduleName = 'protoPaletteData' try: file, pathname, description = imp.find_module(moduleName, [self.dirname]) module = imp.load_module(moduleName, file, pathname, description) self.data = module.protoData except: print "protoPaletteData doesn't exist" return 
-

robsullivan
-
- Posts: 24
- Joined: Mon May 21, 2012 6:06 pm
- Location: Dublin,Ireland
by Nemesis#13 » Wed Oct 03, 2012 5:34 am
Yeah, got the same error message.
It seems the project was abandoned. This is kind of typical for university projects. They're pretty rarely actively maintained.
-

Nemesis#13
-
- Posts: 1041
- Joined: Mon Aug 04, 2008 8:09 pm
- Location: Germany
by P1trs » Sun Feb 03, 2013 7:11 pm
Is this still working? I have only first 4 options in File menu, the rest isnt there.

-
P1trs
-
- Posts: 45
- Joined: Sun Jan 06, 2013 7:39 pm
- Location: Czech Republic
-
Return to Panda Features in Development
Who is online
Users browsing this forum: No registered users and 0 guests
| | |