Josh

From terrain.frag: float slope = asin( worldNormal.y ); slope = 90.0 - slope * 57.2957795; You may have to fiddle around with it a little for rads/degrees.

Sorry for the fierceness of my earlier posts, I've been very irritable lately due to some technical challenges. I'm more inclined to do this kind of thing for the Leadwerks3D documentation, because it's planned to last for a long time.

The position of a joint is the point where it rotates around. If you want the child joint to swing around the parent, the joint position should be the same as the parent's global position.

Yes, don't let my positioning of it as a "visual game design tool" scare you. You've still got an API-oriented engine under the design layer. I'm just adding a layer of control designed for people who don't want to program. Who knows, you might even find it useful for some tasks. I think C++ is the best language to document things in, because it is a standard everyone can follow along. I can't really write syntax descriptions in Lua since all variables have no type. It's easier to convert a C++ examples into C# or Blitz or Lua than it is to go from another language to C++.

That makes sense to me. It's kind of silly to have a full page of code just to demonstrate Entity::SetMaterial or something like that. If you look at the Vec3 operators, I made small examples that aren't entire self-contained programs. Sometimes I need to stop being so pedantic about everything.

Find the mesh's topmost parent, or the first parent that is a model.

Wikis are much easier to edit. The table of contents is handled automatically, and internal links can be added just by surrounding a work with [[brackets]]. It probably would take three times longer to edit all that HTML, and every change would be painful. Plus, people want to be able to search them and not everyone will think to use Windows search (I think they messed it up in recent versions, too...one more reason I prefer XP. ). I would have to create all accounts manually. Apparently there was at one time a bridge for IPB and MediaWiki, but I am not sure if it works. Then there is the issue that I have to be able to answer all questions about these docs, and if it's something a user added, I might not be up to date on that knowledge.

Lately I've been talking a lot about making non-programmers happy, so here's something for the coders. B) For Leadwerks3D documentation, I considered three possibilities: -IPB-based docs -Wiki -Offline CHM files Each has their own strengths and weaknesses, as always seems to be the case. IPB A bit slower, harder to organize, harder to edit, looks really good and consistent with the site, search requires quite a few clicks to get where you want to go, missing table of contents is a bummer for long pages. Wiki A target for spam, doesn't match the main website, user-written docs cause fragmention and a mix of official and unnofficlal information, nice table of contents, good searchability. Offline CHM Fast, doesn't require internet connection, easy to edit, Windows-only. I dismissed offline docs simply because we wouldn't be able to post a link to refer people to a certain page. I decided on a wiki because of the better search functionality, table of contents, and ease of editing. Here's what I have in mind for the docs. Because Leadwerks3D is written in C++, we're able to document members, constructors, operators, and other stuff we haven't had access to in the past. Best of all, almost everything works exactly the same in Lua, including function and operator overloading. http://www.leadwerks.com/newwiki/index.php?title=Vec3 I'm also a big fan of the ease with which we can add internal links. For example, the Vec3 members in the AABB class documentation link straight to the Vec3 class page: http://www.leadwerks.com/newwiki/index.php?title=AABB#Members To avoid spam, and to make sure I can answer any questions about the contents of the wiki, it's going to be read-only. Community tutorials have been very useful in the past, and we're going to continue that going forward, either through a subforum or database for Leadwerks3D tutorials. I think having one page per command and an example for every single command has been more redundant and time-consuming that we have needed. I want to list the syntax for each command only once, like this: http://www.leadwerks.com/newwiki/index.php?title=Entity#SetPosition Instead of making a lot of redundant examples (Do we really need a page of code for Entity::SetPosition() AND Entity::SetRotation()?) I hope to provide more comprehensive examples showing how to actually do something, and how the functions can be used together to do interesting things. In general, I want to go into much more depth with the Leadwerks3D documentation, on all aspects of using the program, because I plan for this iteration of our technology to have a pretty long life. If you have any suggestions, just let me know.

What you're complaining about is the size of the Leadwerks community and the number of people writing documentation. I do not have any control over that at this time and can't provide that. I could lie and say "sure, I will think about doing that" but I don't have time and it's not going to happen any time soon. I try to stick to what I can do a good job of, and build off of that. Writing tutorials about 3ds max is beyond the scope of what I provide. So far, you have sent me an executable that won't launch, a password-protected zip file with no password, and another corrupted zip file. I'll help you identify where your bottlenecks are, but you need to give me something to look at on my machine. Some of the issues you point out are why I eventually want to have a Leadwerks modeling program, so we can have control of the entire art pipeline. As it is, writing documentation for 3ds max would only assist a fraction of our users.

I know enough about how it will work, it's just a matter of hard work.

I don't have a password for your package. I don't have the resources to write a blog about how to use 3ds max. Most people don't even use that program.

Fewer materials is better. Fewer polygons is better. Lower resolution textures are better. Fewer entities are better.

There is no formula for making models that will result in optimal rendering. There's a lot of ways a scene can be made slow. Generally, you want to keep your entity count to a minimum, so eliminate any entity hierarchy from your models unless it is needed. Turn full statistics on in the editor and post screenshots. I tried to run your executable, but it won't launch.

Turn full statistics on in the editor and post screenshots. I can't look at your models because they're all in a password-protected pak file.

Already compiling it into Leadwerks3D, thanks Darren!

File Name: Asphalt File Submitter: Josh File Submitted: 25 Aug 2011 File Updated: 27 Aug 2011 File Category: Materials Resolution: 1024x1024 This gorgeous asphalt material comes in three variations. Normal maps, material files, DDS textures, and TGA files are included, with a total of six textures. Click here to download this file

File Name: Concrete Floors File Submitter: Josh File Submitted: 25 Aug 2011 File Updated: 27 Aug 2011 File Category: Materials Resolution: 512x512 For the first time ever, this concrete floor set is available in a standalone package. TGA and DDS files are included, along with normal maps and Leadwerks Engine material files. Five materials are included, for a total of ten textures. These textures can be mixed and matched to create sidewalks and streets with a consistent design and feel. Click here to download this file

File Name: Brick Walls File Submitter: Josh File Submitted: 25 Aug 2011 File Updated: 25 Aug 2011 File Category: Materials Resolution: 512x512 For the first time ever, our brick wall textures are available in a standalone package. This pack of 15 brick wall materials, with normal maps included, for a total of 30 textures. You also get one long-lost painted variation that has never been released to the public, and an extra concrete base trim material. Click here to download this file

Right, a lot of people can do that, but the problem is we then branch the code, and each programmer becomes an island. This causes the rate of collaboration to be pretty low. With a built-in navigation system, we can share AI scripts and they will all work together. We can even write different AI scripts and make them battle. In the past, I figured that my job is to provide the graphics and physics foundation on which gameplay is built, and then let the user take over. I don't think that approach has worked out very well, except for a few people who already know how to write games.

I don't know if I would recommend that, although it would make the forces symmetrical. Joints have a parent and child, but I don't think they should work differently, as long as they are both the same mass. You'd have to ask on the Newton Dynamics forum for more detail.

I'm focusing on the gameplay features first and foremost. Pathfinding and flowgraphs are more important than having another post-processing effect.

Okay, I have a large amount of navmesh generation code compiling. It's nowhere near working, but I have learned some things. The most important thing to understand is that recast is NOT a library; It's an open-source program. The code doing the heavy lifting is very impressive, but this thing was not designed as a general library with commands to be called from an external program. You've got to extract the parts of the program you want, and try to comment out all the calls to things you don't want, like OpenGL rendering, the GUI, etc.

I found some recast code that actually makes some sense. Fingers crossed...

Yeah, but 2D voxels are just a fancy way of saying a grid.

Yes, but those are all node or grid based, are they not?