Josh

Here's what a script with a lot of unnecessary variables looks like: --Expose values here you want to modify in the editor --Vec3 speed 1,2,3 --bool state true --Entity target --int health 100 --float smoothness 10 --Material material --Sound opensound --choice style "fast","slow","blinking" --choiceedit style "fast","slow","blinking" --string name "Bob" --path file "test.txt" --Vec2 rasterpos 2,2 --Vec4 shape 0,0,1,1 --Do initialization stuff here. function script:Create() end --This function gets called once per world update. function script:Update() end -This function gets called once per physics update. function script:UpdatePhysics() if self.state then self.entity:Move(self.speed,false) end end --This functin gets called any time an entity moves function script:UpdateMatrix() end --This function gets called once per world render, if the entity is drawn at all. It will only be called once at most. Animation should be performed here. function script:Draw() end --This function gets called once per camera render. It will be called each time an entity is drawn. function script:DrawEach(camera) end --This function is called when the entity is freed. function script:Free() end function script:Enable()--in,out self.state=true end function script:Disable()--in,out self.state=false end

The fastest way to do this is to render from one texture to a buffer, halving it each time. This is how downsampling for bloom works. Any downsampling done on the CPU would be far too slow. I don't generally worry about devoting time to stuff for real-time cube mapping because it isn't a feasible technique to begin with. You're talking about rendering the scene 6 extra times.

One thing I love about constructive solid geometry modeling is that texture mapping is sooooo much simpler than 3ds Max. Most of the time the automatic texture mapping works fine, and when you do need to adjust texture mapping by hand, CSG texture mapping tools are still much easier. The justify buttons line a texture up along a face, or a group of faces. Although using these tools is fun and easy, programming them is another matter. I dreaded the implementation of the texture justify buttons, but it wasn't that hard. It doesn't account for rotation and scale yet, but a basic implementation turned out to be surprisingly easy. I guess after writing 3D World Studio five times, I am starting to get the hang of this: Smooth groups are working as well. Leadwerks3D will be the first CSG editor ever (AFAIK) to support real-time smooth groups. In the example below, we have a beveled corner we want to make rounded: To round the corner, select all the faces you want smoothed together, and press one of the smoothing group buttons. This will assign the selected faces to use the smoothing group you press. You can add multiple smooth groups to a face. Faces that have one or more smooth groups in common will be smoothed together: Here is the resulting rounded corner: Finally, I am starting to narrow down the visual theme for the new editor. Since we use the standard Windows and Mac interfaces on each operating system, it makes sense to use the standard Windows Office/VS icons whenever possible. One side benefit is they also look great on Mac, strangely enough: That's all for now. I've had a lot of fun designing the "perfect" workflow for game development, and can't wait to show you all the finished product this summer!

There might be an option like "Export vertex normals" or "Export smooth groups" you can change.

This is an issue with your modeling program. Whatever the normals are in the exported FBX file are what Leadwerks loads.

You don't need to do that by hand. The engine does it automatically.

I like this, it's a GUI library that isn't complete garbage. Garry is a good coder.

That's a pretty good description of how the vegetation system works. Of course that is all automated.

CSG is a great way to quickly and easily produce levels, and the editor is even fun to write. I added another tab next to the scene and project tabs where you can select objects to create. The CSG texture mapping and smoothing controls also reside on this panel. I'm still playing around with the layout, but here is what I have now: CSG brushes are now entities, and can be arranged in a hierarchy. Check out the scene hierarchy that gets created when you create a compound brush object (a shape made of many brushes): You can drag brushes around and change the hierarchy, and traditional CSG editing still works, amazingly. I'm sure glad we have reliable transformation commands or this would be impossible! Here's another nice shot:

Still in progress, but these are good: http://combathelo.blogspot.com/2011/10/c-scope.html http://www.leadwerks.com/werkspace/topic/4024-small-update-with-some-characters-in-gameplay/

The new CSG editor is coming along nicely. Yesterday I implemented CSG rotation and skewing, and today I got object center and edge selection working. 3D World Studio uses GL_SELECT mode to handle picking in orthographic viewports, but this stopped being supported in ATI drivers a few years ago! I implemented a CPU math routine for picking brush edges. In orthographics viewports, brushes can be selected by clicking their center or any edge, while models only use the center for selection. (This is how Valve's Hammer editor does it.) If this feels weird I can implement an edge-picking algorithm for models, but I think the speed of this would not be good with complex models/scenes. The editor is starting to look and feel like a real editor, and we'll soon be able to start producing the level for our example game. It's neat to see a tool with a modern take on a proven level design technique. I have some map files saving and loading. I'd like to use an ASCII based format if possible, but that may be too slow, especially on mobile. Here's a sample of the file format I am using right now: Map { Version: 3.0 Brush { ID: 203099704 Name: "Box" Position: -0.999999881, 10.0000000, -20.0000000 Rotation: 0.000000000, 0.000000000, 0.000000000 Scale: 1.00000000, 1.00000000, 1.00000000 Color: 1.00000000, 1.00000000, 1.00000000, 1.00000000 Material: "models\buildings\guardtower\plaster.mat" Vertices { 0: -1.00000000, -10.0000000, -10.0000000 1: 0.999999881, -10.0000000, -10.0000000 2: 0.999999881, -10.0000000, 10.0000000 3: -1.00000000, -10.0000000, 10.0000000 4: -1.00000000, 10.0000000, -10.0000000 5: 0.999999881, 10.0000000, -10.0000000 6: 0.999999881, 10.0000000, 10.0000000 7: -1.00000000, 10.0000000, 10.0000000 } Face { Indices: 0,1,2,3 Plane: 0.000000000, -1.00000000, 0.000000000, -10.0000000 MappingPlane[0]: -1.00000000, -0.000000000, -0.000000000, 0.000000000 MappingPlane[1]: -0.000000000, -1.79489679e-009, -1.00000000, 0.000000000 Material: "models\buildings\guardtower\plaster.mat" } Face { Indices: 7,6,5,4 Plane: 0.000000000, 1.00000000, 0.000000000, -10.0000000 MappingPlane[0]: -1.00000000, -0.000000000, -0.000000000, 0.000000000 MappingPlane[1]: -0.000000000, -1.79489679e-009, 1.00000000, 0.000000000 Material: "models\buildings\guardtower\plaster.mat" } Face { Indices: 0,3,7,4 Plane: -1.00000000, 0.000000000, 0.000000000, -1.00000000 MappingPlane[0]: -1.79489679e-009, -0.000000000, -1.00000000, 0.000000000 MappingPlane[1]: -0.000000000, -1.00000000, -0.000000000, 0.000000000 Material: "models\buildings\guardtower\plaster.mat" } Face { Indices: 5,6,2,1 Plane: 1.00000000, 0.000000000, 0.000000000, -0.999999881 MappingPlane[0]: -1.79489679e-009, -0.000000000, 1.00000000, 0.000000000 MappingPlane[1]: -0.000000000, -1.00000000, -0.000000000, 0.000000000 Material: "models\buildings\guardtower\plaster.mat" } Face { Indices: 4,5,1,0 Plane: -0.000000000, -0.000000000, -1.00000000, -10.0000000 MappingPlane[0]: 1.00000000, -0.000000000, 3.58979357e-009, 0.000000000 MappingPlane[1]: -0.000000000, -1.00000000, -0.000000000, 0.000000000 Material: "models\buildings\guardtower\plaster.mat" } Face { Indices: 6,7,3,2 Plane: -0.000000000, 0.000000000, 1.00000000, -10.0000000 MappingPlane[0]: -1.00000000, -0.000000000, -0.000000000, 0.000000000 MappingPlane[1]: -0.000000000, -1.00000000, -0.000000000, 0.000000000 Material: "models\buildings\guardtower\plaster.mat" } } }

I just calculated the wave height at the object's position. I didn't have to calculate the whole ocean field, just the height at the position I was interested in.

Absolutely. That's what I do in the editor. There's a secret callback in the camera class like this: framewerk.Main.camera.DrawCameraHook=DrawCameraHook Function DrawCameraHook(camera:TCamera,stage:Int=0)

In Leadwerks Engine, probably no since there is no real debugger. In Leadwerks3D, yes.

Let me put it this way: When I use a third party library, I have code I did not write. That means it's out of my control to fix or even understand. I try to minimize the amount of code I didn't write that I use: zlib enet freetype lua glew recast newton tolua++ openal The only time I ever needed Boost was when I tried using LuaBind, and ToLua++ turned out to be much better. It was a relief to delete the Boost folder.

I call it **** because it's a lot of code that may not compile/work on every platform we deploy to. Therefore, it is something to be avoided.

I think you will find Leadwerks3D to be a lot easier to port. You can probably comment out systems you don't want, or just leave them there and they will take no resources. Everything is pure C++, with no commercial third-party libs, and no **** like Boost built into it. The engine, including all libraries, is about 200,000 lines of code.

Right but your system is not compatible with anyone else's code. This will give us all a standard framework for script interactions so all our script objects will play nice together, and it will be zero overhead if you don't use it.

Yep. I thought it sounded fancier.

I would create a brush, set it as a trigger field, then connect the brush to the door.

Yes.

It's a way to let designers access script functions in a visual manner. Script programmers can write in their functionality, then have it available for everyone to use in a standard framework.

I'm not interested in making a visual programming language. If that's what people wanted, they would be using the C4 Engine: Once you start writing a real program with such a system, it quickly becomes unmanageable. People might say they want this, but that is because they have no idea how complex the actual result would be. You end up with something neither artists nor programmers understand. Instead, I am interested in a system to connect objects to control interactions using predefined functions. The code that makes things happen is in script, and the visual tool lets the level designer control sequences of events.

Today I implemented the last two compound primitives. Tubes are the same as in 3D World Studio, with parameters for the number of segments and thickness. Since the Leadwerks3D editor supports smooth groups, another new compound primitive has been added. A torus is a "donut" shape. These can be used to make curved pipes and other things. Here are the two compound primitives, side by side: Smooth groups and new primitives in Leadwerks3D allow you to create new kinds of geometry which were traditionally not possible with CSG editing: An interesting case occurs when a torus' cross-sectional radius exceeds the radius of the ring. At this point the shape folds in on itself, eventually degenerating into a sphere. To prevent this from occurring, the creation function automatically adjusts the cross-sectional radius, as shown in the image below:

Not in particular, the workflow in the editor is way too specialized for that. It isn't like you just click a toolbar to select with the mouse, click another to rotate, click another to translate. That kind of behavior is easier to program, but we care most about making a really easy to use editing workflow with a minimum number of mouse clicks.