Josh

Hmm, I ran this through GMFDump and the vertex count for four surfaces is 65536, which should be the maximum number: http://www.leadwerks...le/358-gmfdump/ FILE Data starts at: 12 { 12 - Version: 1 MESH Data starts at: 28 { 28 - Matrix: 1.00000000, 0.000000000, 0.000000000, 0.000000000 0.000000000, 1.00000000, 0.000000000, 0.000000000 0.000000000, 0.000000000, 1.00000000, 0.000000000 0.000000000, 0.000000000, 0.000000000, 1.00000000 PROPERTIES Data starts at: 104 { 104 - Keys: 1 108 - Keyname: name 113 - Keyvalue: U3D_STATIC_MESH } SURFACE Data starts at: 141 { PROPERTIES Data starts at: 153 { 153 - Keys: 1 157 - Keyname: material 166 - Keyvalue: } VERTEXARRAY Data starts at: 179 { 179 - Vertices: 65536 183 - Data type: 1 187 - Variable type: 8 191 - Elements: 3 } VERTEXARRAY Data starts at: 786639 { 786639 - Vertices: 65536 786643 - Data type: 2 786647 - Variable type: 8 786651 - Elements: 3 } VERTEXARRAY Data starts at: 1573099 { 1573099 - Vertices: 65536 1573103 - Data type: 3 1573107 - Variable type: 8 1573111 - Elements: 2 } VERTEXARRAY Data starts at: 2097415 { 2097415 - Vertices: 65536 2097419 - Data type: 5 2097423 - Variable type: 8 2097427 - Elements: 3 } VERTEXARRAY Data starts at: 2883875 { 2883875 - Vertices: 65536 2883879 - Data type: 6 2883883 - Variable type: 8 2883887 - Elements: 3 } INDICEARRAY Data starts at: 3670335 { 3670335 - Indices: 390150 3670339 - Mode: 7 3670343 - Variable type: 7 } } } }

Right, but the next step is an actual HTML-based GUI. So it's not a complete solution at all, just an extra step that might lead to a solution.

I agree completely. However, I think if we simply add a command set for creating buttons, sliders, etc. the next request will be a visual designer built into the editor. Then we'll be in the position of having to go back and redo something, because we didn't do it right the first time.

I'm of the opinion that every feature we add needs to be really well thought out, and really well done. I'd rather wait on this so we can come up with something that really meets the need well.

http://www.leadwerks...dwerks-engine-2 Yes, but it's cheaper overall to buy LE2 now and then upgrade. Yes.

We're getting close. I'm trying to focus on three things with the first release of the new engine: -Support for gameplay mechanics (script system, flowgraph, integrated pathfinding) -Really good editor (built-in level design tools, easy art pipeline) -Multiplatform support (Launching for four platforms on day one) There will be some features LE2 has that the new engine initially lacks, but I already know how to do them, and they are planned for further down the road. We're progressing in the order it makes sense to develop.

I've been working on a completely new engine for the last two years, and you just came along towards the end of development. My blog has a lot of details about the process: http://www.leadwerks.com/werkspace/blog/1-joshs-blog/

The new engine supports iOS, Android, Windows, and Mac. C++ and Lua are what most people use. FBX, Collada, OBJ, and a couple others. Physics are built on the new Newton 3.0, but are a modular component that can be replaced with other libraries.

Yeah, I think joints need to be a separate entity class. However, they will not use the entity parent and first child for the joint bodies, as I originally had thought they could. Thanks for the discussion.

I'm not dealing with that yet. The way I would do it is make the frame the parent, then make the balls children, connected with one hinge each. Using two ball joints would not be anything close to an approximation of a string, because a string only exerts a force if the distance between two bodies goes beyond some distance. A ball joint will actually push connected bodies away if they are too close together.

Physics works great with scaled entities: For joints in the new engine, I am considering something fairly radical. In Leadwerks Engine 2, joints were just a class that wasn't an extension of the entity class. I was going to make a new Joint class that extends the Entity class. The problem is you would end up inserting a ton of intermediary joint entities into your model hierarchy, which would hurt the editor's ability to reload models on the fly. What if joints were just a feature in the Entity class? You could set an entity's joint mode and that would create a joint between itself and its parent. You could go through the hierarchy of a character and easily set up ball and hinge joints within the model hierarchy to make a rag doll: Of course this means no entity can be the child of two joints. Joint hierarchies would have to go one-way. For example, if you had a connection like this: [Parent] - Joint - [Child] - Joint - [Parent] It would have to be arranged like this instead: [Parent] - Joint - [Child] - Joint - [Child of Child] For example, in the picture below #1 is the top-level parent, and the children are numbered as they descend. If the blocks are each connected with joints, you will run into problems with the fifth level down, because you are trying to connect the child to two different parents: Are people really going to be making suspension bridges that disconnect and reconnect multiple times? Not sure yet if this would pose a problem or not. However, it would be super convenient to be able to load up that buggy model and add joints to the wheels and turret, without having to create and position new joint entities. It totally eliminates the problem of having to figure out which entities are attached to which joint. --EDIT-- Hmmmm, maybe this isn't such a hot idea. Here's a situation where the design would totally fail: Since our physics are the only ones stable enough for robotics and scientific simulations, I think it needs to be able to accommodate complex machinery.

This is just so cool. You can generate simple primitives for any entity. A convenient "Fit Shape" button will wrap the primitive around the entity, with an option to include the entity's children. However, the real power comes when you generate physics shapes from models. You can right-click on any model and get a menu to generate a physics shape. The polygon mesh and convex hull will look familiar if you've used the PhyGen tool in Leadwerks Engine 2. There's also a new option called "Convex Decomposition". Convex decomposition is an advanced algorithm that takes a polygonal mesh and outputs a series of convex shapes. This is helpful because real physics calculations require geometry with actual volume instead of just being a polygon soup. Convex decomposition can turn any polygonal mesh into a physics shape, such as the Stanford bunny shown below: This means you can generate accurate physics shapes for any model, without creating special physics models in 3ds Max or Blender. Take complex objects like this Utah teapot and generate a physics shape for it, then attach that shape to the model and save it as a prefab. Here you can see the physics shape that was calculated for the teapot using convex decomposition. Navigation is turned on to make the teapot into a dynamic obstacle AI will avoid going through: It's taken a long time to build a game development platform that accelerates development without restricting you, but I think the results are worth it. I hope you are looking forward to using these tools as much as I am.

It's difficult to define, which is why we err on the side of caution. Having said that, I don't have any problem with any of the things you listed in the quoted paragraph above.

We make game development software, you make games with it. I do not want users making game development software using our engine, because if they competed with my software, they would have a huge advantage. It has come up before. When you talk about "mods" no one can ever define what is a mod and what is a game. I've asked people in the past to write a detailed description of exactly what they want the game player to have control over, but no one has ever bothered to write something up in as much detail as I would want. Overall it's cheaper to buy LE2 now and upgrade to the new version, than to wait for the new version. And you'll get access to it sooner than you would otherwise. The programming API is very similar, but we are not attempting to "convert" games.

Leadwerks supports up to 65535 triangles per surface.

That's how I did the AI in Metal. They went to the position they last saw you, and if they had a clear line of site to see you before they got there, their target destination was updated.

One easy improvement would be to have a color for shallow water, a color for deep water, and a depth value that controls how it changes. Shallow ocean water is usually turquoise, changing to deep blue as it gets deeper:

We have that number somewhere, or at least an estimate. I think the situation on mobile is incredible right now. If you put out a pretty good game on mobile, it's in the top ten by default, because there are so few good games.

True, but I think at that point you are getting into more advanced AI that can't be easily automated. You might have a few waypoints set up throughout the scene the enemies know to go to, and then just use the pathfinding to steer them around. There's a lot of ways to make them behave, which makes it a lot of fun to work with.

It's always good to get a second set of eyes on your work. Sometimes when you focus on something so long, you can't see it the same way others do.

It works on all geometry. The algorithm internally uses A*, but it's not a grid.

Eventually, but they aren't high-priority right now. There's some deformable body stuff in Newton 3, if you want to take a look. True, I am breaking my own rules. It's just that when one company's guerilla marketers dominate the conversation, the things I noted don't get noticed until someone points them out.

FYI, the actual percentage of iOS games made with Unity is 0.83%. (Less than one percent, not 83%.)

Normally your enemies would be scattered around the scene and attacking you from different angles. One technique in Left 4 Dead is to run into an area, shoot a few zombies, then retreat so they all come running at you from one direction, and are easier to shoot. So I'm not sure that behavior is a bad thing.

I don't need money right now. Even if I tried hiring more coders, they would only slow things down at this point.