Panda3D Wysiwyg Editor

Would you want a Panda3D Editor

  • Yes
  • No

0 voters

Hey Forum!

So I just stumbled upon Panda3D, and I am really impressed :smiley:
However the programmers only interface of Panda3D, is restrictive to only bring programmers to the party :frowning:

I’m sorry you guys properly get this alot but you need a Level editor! Like Unity3D or even IRRedit, I realize that everyone who requests this is a nonprogrammer and an amateur game enthusiast, and therefore noone has every started a serious Panda3D Editor, but if anyone with the required skills read this, this a Cryout from alot of n00bs! :unamused:

This has been asked a lot here, and there is a thread that people discussed this topic. The biggest reason Panda really does not have an editor is because it will not work for everyone.

There were actually many attempts to create an editor in the past, but most of them hung in the air at some point or never got released in the first place. For various reasons, I presume.

Still, let’s get one thing straight – you can’t make a game without programming. And that’s true for Panda, Unity, UDK, Source or anything else out there. Even Kismet requires you to know what you’re doing – it’s not a magic bullet.

A level editor for Panda is needed, granted, and that’s why I’m writing one. But it’s needed because the Blender-as-level-editor pipeline is exhausting and doesn’t work in the long run (at least for me it just takes too long to tweak stuff in a non-wysiwyg manner). It’s also needed so you can extend it by stuff that you need to build levels for your particular game – setup entities, way points and what-not.

BUT (and that’s a big but) that’s the thing. First, you need a game, not to mention you need to extend the editor, if there is one. And that means programming. There’s no way around that.

Panda is not a modding tool where you have ready-to-go stuff underneath it to run your levels with. It’s a general purpose game engine that you must operate from the code level. In fact, Panda doesn’t even have a map file format, because it wouldn’t have anything to run it with. Heck, there’s even no concept of a “player” present in the API, because that’s your responsibility, that’s what you code when you write a game.

In fact, I think that an editor is actually only needed when you start making some serious stuff. Otherwise, the Blender pipeline is enough, especially since no editor can write your game for you.

Depends on what you mean by level editor. Has worked perfectly fine for me.
maybe if egg loader supported some built-in tags it would be easier for newbies.

For instance, no live lighting preview, so you need to export->run->check->tweak->loop(). The same goes to many other things, like materials. Not to mention you must deal with lights by setting empties with tags, which isn’t the most handy way of doing it.

I don’t think Collada would cut it too, because there would still be no wysiwyg, which is important when you have to make stuff fast.

Empties with tags are generally problematic because they all look the same. That means you have empties used for all kinds of things, but you don’t know which does what unless you select it and look at the name, or the tags.

Not to mention that setting tags is frustrating, because it’s very error prone (typeos and not remembering exactly the name of a tag), and since you only get to know you’ve made a mistake after you’ve exported and loaded the map, it can make one weep. At least I’m speaking for myself.

I’ve used Blender as a level editor for a long time now, and it’s worked very well for me too. However, I think that it’s just time consuming and problematic when it comes to making more complex levels.

You could just say “no realtime preview”. I agree with that. For realtime preview of lights/materials/modifying transforms, I just use simple popup GUIs and in-game console in the game. But the ability to use the same program for both 3d modelling/animating and level editing, plus using the same program for different game engines is a big plus, I would probably not use a level editor like IrrEdit if there was one for Panda3d because of this. And because I would have to extend it to because of all the custom stuff like terrain paging.

Maybe I just don’t know what I’m missing because I haven’t worked with “real” level editors too much.

If the Blender pipeline works for you, that’s great. I’m not saying everyone should want or need a level editor, it all depends on how and what you do. For me, Blender is great as a modeling software, but as a level editor it’s inconvenient. That’s all.

Blender is basically a level editor, for the Blender Game Engine. That’s what the Logic panel and tags are for. There is no realtime preview if you want to use another engine obviously, but like I said you can just write some in-game GUI panels.

But yeah, use whatever works for you.

And that’s basically what a level editor is :wink:. Just instead of in game panels I have 4 Panda windows embedded in GTK viewports, lots of buttons and a couple of gizmos.

I know that Blender is a level editor for the BGE and I know exactly what tags are for. I used them this way and I don’t think it’s a good enough pipeline for me. I don’t really understand what you’re arguing about… I would understand if I were whining that someone should write a level editor, because Blender doesn’t work for me, but I’m not – I see a need for an editor, and I write one. I made it clear in the first post.

Besides, Blender was adopted as a level editor, not built with that in mind. This makes a huge difference. There’s a reason games are usually built in Hammer, Unreal Editor, CryEngine Sandbox and the like, and rarely in Max, Maya or XSI, which are Blender equivalents.

I don’t know. There isn’t an export functionality.

You just made some points why Blender pipeline is insufficient. I disagreed with some of them. I think for someone else reading this thread these posts might give a better idea on what they need.

I am in the middle of programming just that. We should combine efforts. I have about half of the mechanics down that I have desired: triggers and events to which you can assign sequences for entities, which point to panda nodes and bullet nodes. I plan on pickling each entity and storing them in a file for each level or whatnot. Most of the time has been spent on planning this out rather than programming, as it took a while for me to wrap my head around panda and bullet’s function and node structure vs what I wanted to implement on my own. I am hoping to have some code to submit to the forums soon enough for sharing and enhancing, as I too think an runtime editor is imperative for some things.

I am working on something like that too at the moment.

Hey. I’m a new guy here, and this is my second post, so hello! :slight_smile: I was wondering, if people want things like realtime preview of lights and materials, and since the EGG exporter already exists and you can write game properties to tags, would it be possible to modify the exporter to export tags from lights, along with their values? What about doing the same with the materials? I don’t know because I’m just starting out with Panda3D, but I was just wondering. Would it be more work than creating a new editor?

we should have a level-editor-writing jam.

I'm writing one too (who isn't?) based on my experiences with Maya and the Unity engine. I've released some gizmos that you can integrate into your own editor too :slight_smile:

Hey, great work! I get the feeling that good gizmos and scene nav are almost the biggest hurdle to building an editor.

Nice post on linking nodepaths and python objects, too. I think the garbage collection solution you came up with is pretty much the same thing that happens in Unity too, where you do everything via the GameObject instance, and everything else including the transform (nodepath) is aggregated on.

I guess your next step might be to create a utility base class similar to Unity’s MonoBehaviour.

Already under construction :wink: I’m currently testing an approach whereby the user doesn’t have to derive a behavior from any specific class; the reason being that I was worried it could “fence people in” to a particular coding style, one that might not be appropriate to the developer.

This does come with its own set of challenges however. I would imagine that both exposing explicitly typed public attributes to the inspector and accessing the nodePath the script is attached to would be less hacky if I just adopted a behavior class-based approach. I’ll probably end up going down this road after all.