Josh

Yes, that idea was ripped shamelessly from 3ds max.

I've considered that, but the 2D views are actually rendered straight to the back buffer. Also, not all supported hardware the engine runs on even support render-to-texture! Now you get an idea of the constraints I deal with.

The scene browser lets you see every entity and brush in the scene, and also lets you arrange entities in a hierarchy. You can add a light to the scene, position it onto a lamppost, then use the scene browser to parent the light to the lamppost model and save the whole thing as a prefab. There's no "mesh" class in the new engine, and entities inherit a lot of the properties that models in LE2 had, like scripts and physics. Models are just MDL files, and generally just contain model and bone entities. A prefab, on the other hand, can contains models loaded from other files, lights, particle emitters, and anything else you can create in the engine. Whereas in Leadwerks Engine 2 you would use a script to create special entities in code and parent them to a model, in the new engine you can place and parent them visually, then save them as a prefab to be used again and again. Top-level models can be dragged around in the hierarchy, but limbs (children contained within a model file) are a bit more problematic. If we allowed the user to create a character, then parent the character's arm to another model in the scene, then delete the character, leaving the arm...you can see how that could cause a lot of issues. What I'm leaning towards is a rule that it's fine to parent the top-level model to something else, and you can add entities within the model's sub-hierarchy, but changing the parent of a model's limb is not allowed. I hope this doesn't confuse people using it, but it makes sense; if you really need to alter an model file's hierarchy, it should be done in the model editor (similar to the texture and material editors you have seen). You can still set different properties like color, script settings, etc. for limbs of different instances of the same model. The map file will just store data that says "attach these scripts to limb number 7 of this model after you load it". This way models will always be reloaded from their original files, and if you alter your model the whole map will be updated. Actually, the more I think about it, the more this makes sense...this is a map editor, not a modeling program. Not shown here, but I am adding a filter at the bottom so you can type in a name and a list will appear of all objects in the scene that contain that name, so you can type in "tree" and find all relevant objects. Hmmmm, come to think of it, maybe I should also add a drop-down box to search by either object name or the name of the file the object was loaded from. The check marks will toggle visibility recursively, though they don't work yet. I'm writing the grid and object selection rendering into the engine, so they'll be some commands like Entity::SetSelectionState(bool mode). I found this easier than a bunch of rendering callbacks, especially when the engine is designed to run multiple renderers. This might come in handy if you are writing any kind of editor.

I've changed my mind on this, but we're going about it our own unique way and it may not be in the first release. Instead of a rigid "plugin" design that attempts to anticipate every possible use, I think a hook/script system is better. 1. The editor runs all scripts in the "Scripts/Start" folder at startup. 2. Scripts can add a hook. Hooks can be added for an event, or they can be added for a bunch of predetermined points in the program. For example: AddHook(HOOK_MATERIALEDITOR_OPEN,"MyMaterialPluginInit") AddHook(HOOK_EMITEVENT,"MyMaterialPluginHook") AddHook(HOOK_MATERIALEDITOR_SAVE,"MyMaterialPluginSave") You can add a menu action the user can add to the menu to call your plugin: function AIEventHook(event) if event.id==EVENT_MENUACTION if GadgetExtra(event.source)=="OpenAIEditor" aiwindow=CreateWindow("AI Editor",0,0,800,600,mainwindow,WINDOW_CENTER|WINDOW_TITLEBAR) okbutton=CreateButton("OK",20,20,80,30,aiwindow) end end if event.id==EVENT_WINDOWCLOSE if event.source==aiwindow ActivateGadget(mainwindow) HideGadget(aiwindow) end end end] CreateMenuAction("AI Editor","OpenAIEditor") AddHook(HOOK_EMITEVENT,"AIEventHook") So instead of being a "plugin" system, it's more like the editor is semi-open source, while remaining more structured than an open-source program, and preventing the branching that always occurs with open source stuff. It seems almost too good to be true, but as far as I can tell it seems like this would allow for unlimited flexibility, without screwing up the editor source code. You could use this to add a plugin with an interface for PureLight, or any number of other things, and everything would occur right in the editor, within the same interface.

I did contact both of them, and even offered to convert their models for them. It sounded like Steve was getting ready, then one day he asked me what I thought sales would be like. I honestly answered I didn't think they would be much at first, but a year from now it could be significant, and it's about getting the system in place and ready. Haven't heard anything from him since. What I really want are the FPSC model packs. Rick is interested, but he's busy right now with their new app maker program.

Actually, I don't think a non-programmer will be any more likely to be able to write script code than C++. It's all the same commands and concepts. If they can't understand code, putting it in another language (Lua) isn't going to help. They might be able to edit a few variables, but that's it...it just opens the door to endless requests for examples for this and that and the other, and then when an example isn't written to their tastes another request comes for a trivial change. At some point, requests for examples just become requests to write their game for them, to their specification. That's why I have implemented our flowgraph system. It's something completely new that largely replaces the need for code, and lets designers use pre-made interactive objects. You'll have to wait and see how that works. This is an example of when listening to literal customer recommendations is suicide. I don't mean you, YouGroove, I mean the hundreds of non-customers who have said the kinds of things I am describing. You want to listen to your customers' problems. You don't want to listen to their proposed solutions, because even if you carried them out exactly as specified there's no guarantee that would solve their problem. Additionally, if you just carry out a recommendation, you won't necessarily even understand the problem, so your solution can completely miss what they are after.

What I'm really attempting to acquire are animated characters, since that is something there is a high need for.

I don't meant 5% of the Leadwerks community, I mean 5% of the larger potential market. Right, and it was a big challenge to figure out how to make things simple without crippling the system, because frankly if I had to make an easy-to-use ****ty engine, I would rather go write high-speed trading algorithms or do something else for work. I mean, simply making easy to use low-quality stuff has no appeal to me. I like to think the design I worked out will make life easier for everyone, without holding back the expert programmers. I started as a map designer.

Cool, looks like recast?

CSG brushes will be saved into the map, or you can save them as prefabs, or convert them to models, or convert them to physics shapes. But normally, CSG brushes will be considered to be unique geometry for a given map. I haven't thought about how much CSG commands will be exposed. Probably everything, because I am building it into the engine anyways, and I have to access it all from the editor. Most days my progress is something like "that thing that used to crash the program no longer causes a crash" so I don't know if that is very interesting.

We have our design parameters. We know the editor should let the user control every aspect of the engine in a visual manner, without having to use any other tools or do any editing of text files. We have 3D World Studio to serve as inspiration for the design and feel of the program. The sky's the limit. You, the users, have told me that you want to invest in a system that does more for you and makes your life easier. I'm happy to provide the basis for your next projects. Thank you for letting me make this for you, because creating 3D tools is what I really love doing. Look at me, I see a CSG editor grid and I get all sentimental. I like having the scene tree and asset browser in tabs on the right. I tried a couple variations of keeping them both visible at once, and I think it looks silly. The down side of using tabs is you can never drag anything from the asset browser to the scene tree directly. Therefore, it makes the most sense to me to have sounds, scripts, and anything else in the properties editor, so you can drag assets from the asset browser to that. This means scripts, sounds, etc. do not go in the scene tree, and it gets used for only entities and brushes. It seems like a good layout and will support all the drag and drop features we need.

I have been unable to obtain sufficient items to do this properly. We only get one chance to make an impression, so I am looking for more models before it is launched.

Probably because Blender isn't rendering a lot of post effects and lighting each frame. It's not any slower than the redrawing in the current editor, but given the choice I'd like to keep the program feeling light and as responsive as possible. There's a subtle difference you feel when a program starts fast, closes fast, and resizes fast. Not sure why it makes a difference, but it feels better.

That's what I meant by "XOR drawing". GDI has some functions to draw a negative brush, which is what you are probably thinking of.

Once any third party gets involved, the user experience is out of my control. Probably 95% of the potential market for software like this won't accept or understand the need for a third party compiler. Even if they do go for it, coding tools are almost always very difficult to set up and poorly supported. That causes a lot of conflict when I am trying to make a system that's easy to use. A lot of people come here with no coding experience at all, see they have to install Visual Studio, and that's the end of it for them. My guess is that describes maybe 95% of the people who might be interested in designing games.

Another common technique is to overlay an XOR drawing and only resize the stuff when the mouse is let go, but that doesn't work for window resizing, and is Windows-specific. It's not a big thing, but I thought some of the programmers might be interested in what I found.

I implemented resizable viewports this morning. This is so much more fun than fiddling around with compiler settings. You can grab the bars between viewports, or the very center space, and drag it around to resize the four viewports. I usually prefer a smaller perspective view, and like to devote most of my space to the 2D views when doing serious editing: You can also drag the views around to make a single big viewport, or just have two viewports visible: In 3D World Studio, when you resize the window the program instantly redraws, even as you are still moving the window. This is nice looking but it can get slow when you have a large map loaded, and it makes the program feel slow. The problem is even worse with a deferred renderer, because you are constantly creating and deleting those big gbuffers. I don't like hearing the graphics card fan kick up just because I decided to resize a window. I'm getting better results by waiting for the user to let go of the mouse before redrawing viewports, but for window and viewport resizing. This has the effect of displaying "bad"/undefined screen regions while the user is resizing things, but it makes the program very fast and responsive. I used to consider those artifacts to be a sort of amateurish trait, but I think this actually works better. The program feels very fast and light, so I think this is actually a pretty good tradeoff. As soon as you let go of the mouse button, the viewports redraw at their new size. --EDIT-- And now we have grids. Starting to look familiar, but new:

http://www.leadwerks.com/werkspace/blog/1/entry-655-tools-and-stuff/ http://www.leadwerks.com/werkspace/blog/1/entry-658-lua-and-c-debugger/ I intend to focus on Lua for examples in the future. It's a lot easier to work with because you don't have to install compilers and code editors for all the different platforms, and it runs the same on everything.

I should correct that, but yeah, lots of people install it on their laptop and their desktop.

I'm really surprised at the speed of that.

It's possible to just drag the four viewports around as you need, so you can make it 2 views or just one. However, with a complex scene I always find I need three 2D views so I can see what the scene geometry really looks like. This editor is being design to work as a complex level designer, not just a tool to drop some models in a scene, so the rules are a bit different from the last editor.

You can select the top-level directory, enable the recursive option, then enter a search term in the filter box, and the results will be filtered pretty near instantly. If you want to view all materials, for example, type in "*.mat" and hit enter.

You've got to submit that last image as a banner! B)

The fantastic Fatcow icon set was recommended to me in the comments in a previous blog post. These are very similar to the Silk icon set, but come in 32x32 and 16x16 versions, have more icons, and better coloration. The Silk icon set is sort of a desaturated pastel tone I don't like, and Fat Cow's icons are more saturated and bright. I had actually considered running the Silk icons through a color-correction algorithm, but Fat Cow has already done the work for me. I knew from the start I wanted our editor to have lots of colorful toyish-looking icons. I love Valve's editing utilities as well as Nem's Tools, even though they are both rather dated. What I miss about these programs is that they embedded 3D tools into the standard Windows UI, so it was easier to focus on the task at hand instead of being distracted by a flashy custom UI you had never seen before. I've always considered homemade GUIs to be amateurish, and even if one looks cool at first, I quickly get tired of it. My goal is to capture the utility and ease of use of programs like this and 3D World Studio, while adding more modern features to make it more friendly to artists. The editor is starting to take on its own unique character: Designing the InterfaceWhat you see here is the result of a lot of different approaches to try to determine the best way to design the layout of a modern 3D editor. The asset browser is built into the main window, but can be resized or hidden by clicking the window divider. The user will frequently be accessing the asset browser, and having it in the main window is better than having it in a separate window, and constantly having to move it around to get it out of the way. Additionally, I felt that having child windows open from a child window (windowed asset browser) was too confusing...more on that below. The default layout of the asset browser is a vertical split with the treeview on the far right. After using a horizontal split for a while I felt really cramped for space. The vertical layout gives you a better distribution of space and plenty of room to view thumbnails. Originally, I had the asset files themselves in the tree with small icons, but I found that 16x16 was too small for a meaningful preview of each file. I tried making the tree view icons bigger, but it wasted a lot of space. Folder icons looked ridiculous at 32x32 and above, and took up more room than they needed. I tried using generic 16x16 "texture", "material", and "model" icons in the treeview, but found it was much easier to identify files by thumbnail rather than reading their name. Finally the decision was made to keep folders in the tree view, with small icons, and have a separate thumbnail browser with bigger icons. The user can adjust the thumbnail icon size, from 32 to 512. I also liked this approach because it is similar to the texture browser in 3D World Studio. The folder treeview is on the very right-hand side by default because the white background would cause the dark 2D and 3D viewports to look even darker. Your eye actually will perceive a darker color in an area of high contrast, so keeping the mostly-white treeview off to the side will make your scenes more easily visible. When you double-click on an asset file, a window for viewing and editing the asset is opened. I considered building a preview window and controls into the main window, but it didn't fit the workflow. Sometimes you will want to drag asset files into an asset editor. For example, you can drag a texture into the material editor to assign a texture to the material. In order for this to work, you have to be able to open the material in the material editor, then navigate the asset browser to where the textiure resides, then click and drag that file into the material editor. This wouldn't work with a single preview window. There's also a good case for having multiple asset editors open at the same time. You might be working on a shader and want to see its effect on a material in real-time. In that case, you would keep both assets open in their editors while working. I also considered making the asset editors a separate application the editor opened, but didn't for two reasons. First, drag and drop operations would probably be harder to code, especially across multiple platforms. Second, and most importantly, I wanted the asset editor windows to always appear on top of the main window, and that wouldn't happen if they were external applications. I also like having the asset editors in their own windows because at any time you can maximize the window and get a nice big fullscreen view of the model, texture, or material you are looking at. This is naturally useful for scripts and shaders as well, where you are editing code and need lots of space. The font editor is shown, and supports both .ttf and bitmap fonts. I implemented my own .fnt format (I think this is an old Window 3.0 file extension, but it's mine now) and a .ttf to .fnt converter. As with all the Leadwerks 3 converters, the editor automatically handles the conversion for you, so you just drop your .ttf files into your project folder and you're done. I don't know of any cross-platform font maker programs, but I will publish the specification for our font format so they can add exporters. It always seems to work best when we just make our own optimal file formats and publish the spec for everyone to follow. Bringing Back Level DesignAs I approach our CSG brush implementation, I find myself growing quite excited over something that was originally an annoyance I did not want to deal with, but the users insisted we merge 3D World Studio with Leadwerks 3. When Leadwerks Engine 2 was designed, I thought CSG was obsolete once dynamic lighting became possible, and we no longer needed special geometry for optimal lightmapping. However, with the loss of CSG I think we lost a reference point in our virtual worlds. It was easy to drag out a room in a few minutes for playtesting. CSG is also fantastic for buildings, and can produce results in a fraction of the time it would take with 3ds max or another polygonal modeler. I'm very eager to see what CSG will look like in a modern implementation, especially if I can work hardware tessellation into it. CSG is an area of expertise for Leadwerks as a company, and I am glad to be drawing on that knowledge to bring something new and different to game design tools. I'm looking forward to a return of the lost art of level design, with a modern flair. Finally, here's a song for you that can be vaguely connected to the subject of this blog, from Alice In Chain's album "Facelift". (See what I did there?) http://www.youtube.com/watch?v=QXPA44Ebg_o

The only thing I know of is to reformat your hard drive, which I doubt you would want to do.