Josh

Most open-source software is written around what makes things easy for the programmer, not what makes things easy for the user. 3D World Studio was written to make things easy for the user. Leadwerks Editor was written to make things easy for me. I think it shows.

In other news, "moneybags" Xaron is now my only customer. I only need to make one sale! XD

I made a fake one in LE2, but I don't like doing that.

I had Hammer, UDK, and Crysis Sandbox open all day yesterday. I took ideas from each: Hammer: Standard Windows interface, four viewports, objects dropdown boxes, texture browser search filter. UDK: Asset browser, asset edit windows. Crysis Sandbox: Tabbed side panel.

According to MS, in America laptops account for like 76% of PC sales. I won't ever buy one myself, because I can always get a better desktop for less money, and I find them awkward to use.

Yeah, I'm going to make all dockable elements derived from a DockableElement class for future-proofing. There are some big challenges there. Would plugins be script or code? If code, the engine API would have to be re-exposed through the editor, because objects your code creates won't be the same engine instance the editor is using. If I use script, then I need to provide a binding for BMX and the engine. It's probably possible, but the debugging isn't as good as the engine's debugging features.

Yeah, I asked Chris and he pointed out that one method required me to draw an arrow to show what to do, and the other didn't. It's good to get a second and third opinion on these things.

Each tabbed item can be moved to the left, right, bottom panels, or popped open in its own window. The left, right, and bottom panels can be hidden and shown by click on the edge, or they can be resized by clicking and dragging. Here I have the asset browser popped open in its own window, maximized in a second monitor:

Please stop by this thread and give me some feedback: http://www.leadwerks.com/werkspace/topic/4987-interface-concept

Tell me what you think. Everything is customizable:

We've had a lot of discussion with the community about the Leadwerks3D script system. The current design is based on a combination of user feedback, lessons learned from Leadwerks Engine 2, stealing ideas from other game engines, and my own judgement. Our goal is to make a really easy and powerful game scripting system, without overwhelming the user with complexity. With that said, I thought I would let you in on how the script system presently is working in our own builds, and the process of using it. To attach a script to an entity, open the Properties Editor. Click and drag the script file from the Asset Browser onto the Properties Editor. A tab appears where all the script properties are displayed: Here's an alternate approach we are playing with. Here, the properties editor is embedded in the scene tab in the side panel. Since assets can't be dragged from the Asset Browser to the Properties Editor (since they are in different tabs) we just right-click on the entity in the Scene Browser, and a standard file request dialog appears, allowing you to choose a script file: Which do you like better? The visual logic editor in Leadwerks3D is called "Synapse". To add an entity into Synapse, drag the entity from the Scene Browser into the Synapse window. The entity will appear as a block, with its attached script components displayed below it in order. The color of the logical block corresponds to the object color in solid and wireframe viewports: You can see the script defines the output and input functions that are displayed in Synapse. Next I'll show you how entities in Synapse can be strung together to make sequences of events and gameplay logic.

So this is fixed?

FYI, even if Leadwerks experiences 0 market share growth (which I don't think will be the case!) we'll be doing just fine. There's a lot of Leadwerks Engine and 3D World Studio users out there. This time around is a little different because I am trying to put something out that is more polished at release.

It's possible for the ray cast algorithm to fall in between triangles and go through an edge where two surfaces meet.

That sounds like the Xcode 4 layout, which isn't bad. What I don't like is that a huge chunk of screen real estate will be empty and wasted when nothing is selected.

It actually worked out this way because of the need for multiplatform support, and the incredible scalability that involves. It's easier to account for everything from the start and design an engine once I know all the constraints on all platforms, keeping the high-end requirements in mind.

It's hard to make an objective test, but I think it will definitely be faster. The engine has no garbage collector (except for Lua, of course) and is written entirely in C++.

As I always do when making design decisions, I tried out several approaches to the properties dialog. Previously, I wrote about embedding it in the side panel, below the scene browser. I liked being able to quickly modify object properties, but I couldn't drag assets like textures and materials from the Asset Browser to the Properties Editor, because they were under different tabs in the side panel. Because of that, I popped the Properties Editor back into its own tool window. The experience of using the Properties Editor in the side panel gave me the idea to have an "Instant Update" mode, in addition to the default "OK", "Cancel", and "Apply" buttons. When "Instant update" is checked, any changes to the Properties Editor are immediately sent to the selected objects, giving you more immediate visual feedback. To add a script component to an entity, drag a script file from the Asset Browser to anywhere on the Properties Editor and release. A new tab with the properties for the script component will appear. Parsing scripts and getting their exposed variables is the next step I will work on.

Compared to the work I've done more recently, graphics are actually relatively simple and minor. A lot of the Leadwerks3D high-end graphics work has been laid out already. The biggest challenge will be a new terrain system that gets rid of the constraints of the old one. Because it's a big challenge, and there's already a ton of work done to make the new engine multiplatform and easy to use, it seems like a good first step to release the first version with one graphics module that runs across the board. There's a long-term plan here, and I love good PC graphics better than anything, so please be patient. I want to build a really easy and useful tool with lots of gameplay features, and not just have good graphics. I haven't tested any yet. By default, my core i7 only supports OpenGL 1.6, so either we'll have to add a basic DX renderer, or an OpenGL 1 renderer.

I'm trying to stay away from anything that isn't cross-platform (especially given that MS thinks all windowed programs are now "legacy apps"). The future of Windows looks very uncertain, and now more than ever I would avoid becoming dependent on any one desktop OS. Just read this article to get an idea of what they are thinking: http://blogs.msdn.co...experience.aspx

Of course. If no shader is explicitly assigned, the engine chooses one for you based on textures and animation properties.

After putting together a pretty complete model of how the logic editor would work, I found myself unsatisfied with the properties dialog. I originally intended to make a standard properties dialog that opened in a separate window, with "OK", "Cancel", and "Apply" buttons. However, the logic editor and properties dialog were both being opened in separate windows that were a child of the main window, with no strict draw order between the two of them. I found it confusing to select an entity in the logic editor, and then have to go to a separate window to modify its properties. I tried moving the properties dialog into the scene browser panel, in the side panel on the right. There was a nice big empty space for it, and it looks appropriate. Normally I do not like interfaces like this because it means the data has to be continuously synced even when you are just editing in the viewports. However, with some clever coding that keeps performance in mind, I think I can get around this problem. It certainly feels a lot simpler to work with. With this many features in the editor, I want to be careful to retain the intuitiveness of programs like 3D World Studio, Property groups are separated by tabs, which I find to be a lot easier to use than a big vertical stack of properties as high as the screen. It also makes editing faster because I only have to fill in the values of the currently visible properties tab. I think it also makes sense to open assets in their own window, while modifying object properties in the property dialog embedded in the main window. You will spend more time modifying object properties while editing. Assets are something that only need to be adjusted once in a while, because they should be left alone and reused many times. The whole properties interface is a class that lets you build an interface, without actually knowing what each control does. The editor entity class has functions to get and set property strings, which can include position, rotation, and other basic stuff. It's quite nice because it allows me to add lots of new properties without having to hard-code any dialogs.

I never thought about it, but you can even do insane things like plug other engines into Leadwerks3D. For example, you could make a Blitz3DSDK-based renderer for it!

Yes, the script debugger in Leadwerks3D is very good.

OpenGLES 2.0