Ogre Forums

Hi,

I'm creating a level designer component suite (ogretoolbox). I'm wondering what artists like most:

* Static IDE with everything in it
* IDE with plugins for each kind of file (so switch in the IDE between dotScene-editing; terrain-config; mesh-material; ...) that you can add and remove
* Basic IDE and separate tools for each kind of file (dotScene-editing, terrain-config editing, meshmaterial-editing, ...)

I'm totally against number 1 as it's too hard to maintain.

pros for 2:
* you can do everything in the IDE

cons for 2:
* the ide can get pretty messy
* you have to start your ide for every file you edit

pros for 3:
* reuse of (good) existing tools
* allows filelink in windows to each specific tool.

cons for 3:
* a lot of tools to start.

But that's from a programmers view. What do you artists think?

Mr. Turner

[Made a Poll]

I'm more programmer then artist, so it isn't exactly me you want to hear but I'll say something nonetheless.

The second method looks the best to me.

You will be probably making it in c++? If you are going to do it in java you could use the eclipse rich client platform. Very extensible and you can easily add/remove/change/udpate/... your plugins. But ofcourse it is only java and I don't know how well the bindings with Ogre in java are.

Getting something similar in c++ would be nice ofcourse, but a hell of a work I think.

Great plan!

I mean, Ogre is fantastic in its nature of programming, but it lacks when it comes to art. What people here are seeing (after so many years), is that artists are getting pinned down because of the lack of support for them.

We need ideas like that freshing out more and more...

What good it does for your project if the programming is awesome but the art sucks just because your artist couldnt work quite good on your engine ? Players dont see programming...

You will be probably making it in c++? If you are going to do it in java you could use the eclipse rich client platform. Very extensible and you can easily add/remove/change/udpate/... your plugins. But ofcourse it is only java and I don't know how well the bindings with Ogre in java are.

Yes the current version is in c++.

Or I could do a mix of both as I am not so keen on reinventing the wheel.

BTW, your project sounds little close to one of my own, where me and my friend were going to take blender and turn it into an OGRE based scene editor, modelling program and game IDE with the syntax and all.

I have been waiting for our engine tests to come out before I made this public, but the time seems right now, so look for an "Evening" topic on the forum...

The result seems to be, that most artist and/or programmers like the plugin-based approach. So I guess that's the way to go then.
We'll be going for the VS.Net approach: solutions with projects and a dockable window for each plugin.
0.1 +/- stable has been released. All that's left for the public release is the linuxport.
For complete roadmap for 0.2, check the site (see signature).

BTW, your project sounds little close to one of my own, where me and my friend were going to take blender and turn it into an OGRE based scene editor, modelling program and game IDE with the syntax and all.

I have been waiting for our engine tests to come out before I made this public, but the time seems right now, so look for an "Evening" topic on the forum...

Our goal was to create a standalone app without the level designers having to be really good at a specific program. So 3dsmax artists can still create their content with 3dsmax and export with an exporter. Then they or someone else can compose / finetune the scene and add physics, sound, ...

Mr. Turner wrote:Our goal was to create a standalone app without the level designers having to be really good at a specific program. So 3dsmax artists can still create their content with 3dsmax and export with an exporter. Then they or someone else can compose / finetune the scene and add physics, sound, ...

Sounds like a description of Yake's Storm Editor Anyway, the recent discussions on various takes on editors are quite interesting.

Maybe we can standardize one or two things in the process so that more than just one tool could be used, at least for certain aspects where they excel each other.

-psy

Speaking as an artiest.

What did you just say?

Honestly, the best thing you can do when making tools for us is.

Give feedback errors that are in ENGLISH not a string of numbers that we must then look up.

Keep the structure in a logical order (not programmer logic lol)

Don’t label things with your code definitions or tags.(what ever you call them) Label them with something that has a real meaning to the user. As in if it’s a water tag. name it that not “W_material_49j_get_texture” (yes I made that up but you get the point).

labling a Config box for an item "dotScene-editing, terrain-config editing, meshmaterial-editing" Has little to no meaning to us.

I have seen a lot of tools that no artiest would use…ever, Mostly because projects of this nature make perfect sense in the naming conventions and structure…. to programmers.

Not artists.

Also some of the best tools are direct from Creation package > Game engine.

To many middle programs makes the art pipline crawl.

2c

I dont know whay this went twice.

I'm an artist and clearly not a very informed one... What's an IDE?

ah programmer logic, you can't beat it. A hint to programmers, imagine a 'car person' crapping on about their twim cam and fully blown hemy and you not understanding a god damn thing, but they don't pick up on this at all... that's how artists feel
The trouble with programmers is they love flexabilty, but they rarely understand effeciency. If something can be done with one command/click then it should be done in one. Programmers tend to turn that into a 20 line program because in some obsure circumstance you might need some other functionality. The key of course is to let them do it in one command, but optionally allow the extra if needed. Even OGRE does this I feel.
So for a scene editor figure out what is used 90% of the time and make it immediately accessable. Camera moving and object moving/selecting for instance should NOT be seperate functions with discreet modes and buttons, it's too slow. We've all got 3 buttons on the mouse with combinations so use them. At the very least have temporary modifier keys (not mode changing keys)

Don’t label things with your code definitions or tags.(what ever you call them) Label them with something that has a real meaning to the user. As in if it’s a water tag. name it that not “W_material_49j_get_texture” (yes I made that up but you get the point). (...)

Good point. I'll certainly take this into account for the next release.

I'm an artist and clearly not a very informed one... What's an IDE?

It's an integrated development environment. It's an environment that includes all tools and software to create a scene in this context. It also means that it's pluggable and can be highly modified. So you can change the whole lay-out. For an artist, it would best compare with 3dsmax / blender.

The trouble with programmers is they love flexabilty, but they rarely understand effeciency. If something can be done with one command/click then it should be done in one. Programmers tend to turn that into a 20 line program because in some obsure circumstance you might need some other functionality. The key of course is to let them do it in one command, but optionally allow the extra if needed. Even OGRE does this I feel.

Yes, I'm aware of that. That's why I also include a "Add 3d object" and "Add light" dialog. So my vision is: allow programmer-artists to do every little thingie manually and in the mean time provide shortcuts for the artists that don't know what a scenenode is.

Sounds like Yake's Storm Editor

Any links?

Mr. Turner

speaking as a pro game dev artist... (im picking up the programming aspects of OGRE slowly) things i think would really help art dev are:

1. particle editing tool
(i wanted to make one myself, but i need to learn a lot more) - to make this the most effective it would need to be able to load multiple particle systems and at least 1 static model (for size reference), and be able to display changes in the particle parameters in real time.

2. a material editor
although i understand multishaders and all their parameters.. its still a hard thing to visualize... (i.e. its hard to imagine what adding the alpha of this to the RGB of that multiplied by a second texture would look like) it would be nice to have a program that could load up a static model and you could modify the parameters of its materials and textures in real time... and as Vectrex pointed out... even if such a program wasnt capable of illustrating every combination of possibilities in a material file, it would still be an extremely valuable tool, in other words -even if it was a rudimentary material tool to get a material started, it would be very valuable.

on a final note... all things an artist needs dont necessarily need to be in 1 program... id personally rather use 5 programs that are really well suited for particular tasks than 1 program that is not as good at any of them.

Alright then what I really want from an IDE is a landscape/heightmap editor and texturer. Apparently this never dawned on anyone but editing landscape in a different tool than the one you're placing entities and objects with is far from advised if you can't view all the objects you've placed while editing terrain. In a lot of cases I have to make changes to the landscape based on the models I'm adding to the environment and I can't easily do that in any terrain editor because I can't see where I've put them!

Of course... this has absolutely nothing to do with your question. In addition I've never used ogre toolbox so it might already have this in which case you're awesome and I will download it immediately.

1. particle editing tool (...)

2. a material editor (...)

on a final note... all things an artist needs dont necessarily need to be in 1 program... id personally rather use 5 programs that are really well suited for particular tasks than 1 program that is not as good at any of them.

Yep, that's why we interact with MeshViewer on Windows rather than creating our own tool/plugin. Don't know what you need exactly, but Material Editing is already a fact in MeshViewer.
Maybe we'll port it to wxWidgets to make it work on all system.
For particle systems: what do you think that is best for the purpose you mentioned (editing, modifying parameters): a standalone program or integrated in the IDE (as a plugin then)? Support for adding it to a scene, will be integrated anyway.
For the standalone program, there's already a WIP somewhere on the forum.

Alright then what I really want from an IDE is a landscape/heightmap editor and texturer. (...)

Yes, that's one of the most important features that we'll also be working on. There has been some wip arround here on the forums, so maybe we can reuse some code and integrate in the scene editor.
But you have to know that Ogre Toolbox is still a quite recent project, so we're working hard on getting a rock stable portable core that we can extend.

Mr. Turner

hmm, well thank you for enlightening me about the Mesh Viewer hadnt come around to using it... im still a noob to Ogre. It is quite a nifty tool, even though its still a little rough on the edges. and i did mean to refer to a stand alone tool as far as a particle editor was concerned. But even though it could be integrated into something else I suppose the only requirment for me to use it would be that it used the ogre engine to display its geometry and particles, otherwise it wouldnt mean much... (i.e. a plugin for max or something that displayed particles in max viewports wouldnt be much use) ...It needs to display things exactly as they will look in-game.

Mr. Turner wrote: ..., so maybe we can reuse some code and integrate in the scene editor.

That's a good point!
I sincerely hope that all those WIPs out there will make them so that it is easy to integrate/embed them into the Ogre ToolBox, or a homegrown in-house gameeditor. (Without tearing apart the whole thing first)

Hi guys, I just got back from holiday in Italy.

It needs to display things exactly as they will look in-game.

The mean reason why I started working on the editor.

I sincerely hope that all those WIPs out there will make them so that it is easy to integrate/embed them into the Ogre ToolBox, or a homegrown in-house gameeditor. (Without tearing apart the whole thing first)

Yes, the problem is that all those WIPs are splattered all over the forum. Anyhow a terrain editor has just been open-sourced, so as soon as the plugin-system is up and running, that will be included.

Mr. Turner

I think this poll is coming out very skewed because almost everyone on these forums is a programmer with some minor art experience, and the ones who are mostly just artists have no idea what you're talking about. I am also just a programmer with some minor art experience, but I think it's kindof silly to think that anyone who is purely planning on using your tool (not programming for it at all) would want anything BUT a single unified IDE, ie option number 1. I understand that as a programmer it's not a compelling idea since it will make coding and maintaining pretty difficult. But if you phrased it more as what you really mean without needing to justify it:

"Which would you rather have, a program that has everything you want in it and it all works great together, or a program that has a bunch of random different subprograms in it that all work differently, or a bunch of completely separate programs that you'll have to keep saving and loading over and over to get anything done?" The answer is that obviously anybody would want Choice One. Nobody wants to switch apps or plugins within an app just for fun; you only do it because you have to because the current app or plugin can't do what you want.

There are already a bunch of scene editors in development which sound great to programmers, ie, all plugin-derived and abstract and separated into modules, etc., etc. But very few that actually do anything useful. I would say you should aim for option 1. I know it's the least fun from a programming point of view, but it's the most useful from an artist's point of view. Artists need something to plop down meshes and materials and move them around, and export to dotScene or something similar. If you spend months and months coming up with a modular app framework that none of them will even notice, you're not really doing them a favor.

I don't agree!
Tell me why 3ds max provides plugins!

jacmoe wrote:I don't agree!
Tell me why 3ds max provides plugins!

So that other PROGRAMMERS can make add-ons for the artists to use. I'm quite sure that the artists would prefer that everything they need all be in one place and easy to switch to. And 3DSMax puts everything they can into the main application; they haven't separated it out into different apps or different plug-ins for polygons, nurbs, materials, terrain, animation, etc.

Adding the ability to load plug-ins so that 3rd parties can modify your application is a good idea. But separating everything into plug-ins and then developing them all yourself is just something that programmers seem to like to do because we get off on reusability and OOD and UML and whatnot

I'm not saying customization ability and pluggable architecture are bad; I'm just saying that when an artist has to go through fifty different tools to get his spaceship into the game, he's not going to think "Ah, what an amazing array of options that I will never use and customization options that the programmers might be able to make something for!!" He's going to think "God this is annoying; why can't they make ONE tool that just WORKS?"

Plugins can be developed in such a way that the editor looks and acts like one application. Essential points are:
1. The framework provides some common functions that every plugin can use
2. There are guidelines and standards that describe how to develop a plugin
3. There is a styleguide that defines the look and feel. Every plugin follows that styleguide.
4. There is a 'vision' about which functionality is needed (as a whole) and which plugin is responsible for which part of that functionality.
5. The development team shares that vision.

So that other PROGRAMMERS can make add-ons for the artists to use. I'm quite sure that the artists would prefer that everything they need all be in one place and easy to switch to. And 3DSMax puts everything they can into the main application; they haven't separated it out into different apps or different plug-ins for polygons, nurbs, materials, terrain, animation, etc.

That's basically what we're trying to do here.
Why don't we stuff it all in 3dsmax? Because it's a modelling application. It's designed for that purpose. Ok you can (and maybe should) do all the basic stuff (moddelling and putting everything in a scene) there, but you can't tell how it will look in-game as you're still depending on 3dsmax renders. I think that would also annoy the artists that would have to modify a bit and re-export, find that it still looks a bit wrong, remodify, ... Plus I don't like the idea of modifying physics stuff etc in a modelling app.
The way I would design plugins is that every programmer that can read a simple doc, can extend the application for his/her artists without the artists knowing that the code behind it is in separate files (like 3dsmax does it).
The problem with a fully static IDE is that in the end you'll have a tool for scene editing, one for terrain editing, without the ability to see them all together. That's why I would go for option number 2 as you still have all basic stuff in the ide and the rest in plugins, but for the artists it's all one application.
I can see your point with the "useless array of options", that's way I intend to make both a quick and dirty way of doing things and an advanced way to tweak some settings. I don't like the idea of only being able to add an object and then being frustrated because you can't change that specific option.

@spookyboo: I totally agree.

Mr. Turner

Mr. Turner wrote:

So that other PROGRAMMERS can make add-ons for the artists to use. I'm quite sure that the artists would prefer that everything they need all be in one place and easy to switch to. And 3DSMax puts everything they can into the main application; they haven't separated it out into different apps or different plug-ins for polygons, nurbs, materials, terrain, animation, etc.

That's basically what we're trying to do here.
Why don't we stuff it all in 3dsmax? Because it's a modelling application. It's designed for that purpose. Ok you can (and maybe should) do all the basic stuff (moddelling and putting everything in a scene) there, but you can't tell how it will look in-game as you're still depending on 3dsmax renders. I think that would also annoy the artists that would have to modify a bit and re-export, find that it still looks a bit wrong, remodify, ... Plus I don't like the idea of modifying physics stuff etc in a modelling app.
The way I would design plugins is that every programmer that can read a simple doc, can extend the application for his/her artists without the artists knowing that the code behind it is in separate files (like 3dsmax does it).
The problem with a fully static IDE is that in the end you'll have a tool for scene editing, one for terrain editing, without the ability to see them all together. That's why I would go for option number 2 as you still have all basic stuff in the ide and the rest in plugins, but for the artists it's all one application.
I can see your point with the "useless array of options", that's way I intend to make both a quick and dirty way of doing things and an advanced way to tweak some settings. I don't like the idea of only being able to add an object and then being frustrated because you can't change that specific option.

@spookyboo: I totally agree.

Mr. Turner

I do of course think there needs to be a scene editor that displays things as they'll look in-game; I wasn't suggesting trying to do it all in 3dsmax.

I do know what you mean; I'm mostly just worried because a few other projects have tried something similar, and spent months and months trying to build the most abstract and pluggable API/IDE they could, with the grand goal that anything you'd want to plug in, you could, until even doing something as simple as "import a mesh and move it around" required learning a new API and getting a programmer to write a specialized plug-in. Just don't get caught up trying to design a gigantic abstract base with the idea that it would be great if a programmer could fully customize the way mouse movement affects the cursor or put months into making the app graphics-engine-independent when in reality the only rendering plug-in you or anyone else will ever build is the OGRE one. A little abstraction is great and all, but it seems like a lot of projects get carried away with it and never actually make anything concrete when their attempts at ultimate abstraction from everything spirals out of control.

The main point I was trying to make was that the artists would prefer option 1; it's only programmers that like option 2, because we're all thinking "Oooh, if he makes this, I can take it, rip out the terrain part, and plug in a terrain module specific to my game, and then hand it to the artist". But that would all be transparent to the artist; he would just see it as the minor annoyance of having to open a separate window to do terrain instead of being able to do it in the main window. So from an artist's point of view, separating everything into plug-ins isn't really worth much. However, it IS a good goal if you expect a lot of people to write a bunch of separate plug-ins for your app, but it's questionable if that's necessary, especially if you plan on releasing the source and it's neat enough that people could make changes to terrain editing by just modifying the base rather than writing to an API.

In your example, I would much rather have terrain editing all done in the same window as scene editing, like in the Unreal Editor. I don't necessarily see why it would be beneficial (from an art standpoint) to have to do it in two different windows or modes within the same app, and have to switch back and forth every time you wanted to change the shape of a hill so you could place a turret on top of it.

In the end of course, it's totally your choice; I was just saying I think your poll would sway much more towards option 1 if you posted it in an art forum asking actual level designers and artists about it, and phrased it as something meaningful that they would see, ie, "Would you rather be able to modify the terrain in the same window as everything else, or would it be better if you had to open a separate window to make any terrain changes?" When you phrase it like that, rather than talking about the ability for programmers to easily modify parts of your app, the answer becomes more obvious. The artists don't care about what the programmers can do to the app; they want the easiest and quickest way to get content into the game and see how it will look in game.

Edited: as to spookyboo's comment; if everything was completely transparent and you're just talking about API structure, so that an artist would have no idea that something's a separate plug-in, well then that's different, and the question becomes meaningless, because the artist has no interest at all in the underlying program structure. But you seemed to be implying what I was saying; multiple windows and modes within an IDE for each function instead of a unified interface. I don't think there's a benefit to anyone outside programmers planning on ripping out chunks of your editor to replace with their own for having everything be within separate windows or mini-apps within the main app.

makeshiftwings wrote:
I'm not saying customization ability and pluggable architecture are bad; I'm just saying that when an artist has to go through fifty different tools to get his spaceship into the game, he's not going to think "Ah, what an amazing array of options that I will never use and customization options that the programmers might be able to make something for!!" He's going to think "God this is annoying; why can't they make ONE tool that just WORKS?"

Speaking as a completely non-programmer. This is 100% true.

One tool, or suite if you will. Plug in? They are good to have. like I said before, Artists have enough outside tools for us to use. Paint programs, modeling programs, ETC.. If you create this tool, it needs to have no middle men involved. I hate using exporters... Why? Because its a step in the pipeline that cannot be reversed.

Having to use two tools to get the object in game is annoying and very ineffective. When we have to tweak something because it doesn't look right having to use "middle" steps to be able to just tweak something is a pain.

Also you should have a way to see updated models in real time, as in, If I import a model, see something wrong in your editor or the engine itself, I should be able to jump back to my modeling program of Choice, make the change and flip back to your editor and hit some sort of "Update model" button. I really hate having to clear the object (and in the processes loosing its position and anything else that doesn't need to change) and re-import it again.

Also, you should make importers for most standard modeling programs.They should not be outside programs! or command line programs, they should be located in the "File > import" options.

Lightwave, 3DS, milkshape (big 3) ETC..

The last thing I can think of, and one that is a major pet peeve for me. Camera control, I'm not speaking of "Game" cameras but the camera of any view in your Editor.

It should all be mouse bound in combination with holding keys. As in, click and drag with the left button will rotate the camera (all directions), and holding booth should do Moving in and out or "forward and back"("Zoom"). Also the use of the space bar while dragging is a common thing in most graphics programs.

Something I would suggest is looking at some popular applications that artists use. Namely for me, adobe products. Take a look at how moving around an image is done there, and mimic it.

Also, (lol) The mouse curser, it needs to change into something when you hover over something in the views when you can do something to what ever it is you are hovering.This is also an indication that you are currently selecting something you can select.

This it will need.

- Lighting
- Terain
- BSP style "Room" importing
- Meash inporting (with realtime updating)
- Waypointing system ("NPC" pathing)
- Metrial editing
- The ability to Slect a mesh and view its proprities in the 3D view (This inclued metrials)
- Sound devices with settings for range, file ETC..
- Difrent icons in the 3D view for each type of Entiey, they need to be a no brainer too, a "Box" dosnt work.
- Plugins are fine but should not be apparent that they are not part of the app.
- Support for every texture file that your intended engine supports (ogre), In the metrial viewr and in the 3d view (even if it is slightly distorted).
- partical editor and a way to atach it to meshes or bones
- Resizable viewports
- a help file in english not programer speek.
- one save as .scene (OGRE scene file)
- The ability to just slect a mesh (3d view) and apply a shader.

Im basicly saying...make it support at its core everything that orge support, but leave it open to being able to custmise it to the project at hand.But ever part needs to be viewable in the 3d view.

One stop shop.

2c

Just as a side not to sum things up. I hate being told i need to download plug in -X- to change the color of somthing.

And he is right.. "whats an IDE"? (no need to answer)