TylerH

I am confused how this is good, the character's physics mesh is never aligned with the animation?

Not to discourage. It has been much more stable now, but I think a physics engine developed by a subsidiary of Intel Corporation is 100x better than anything Julio Jerez is going develop as a Hobby Project in his SPARE time. Those are my only comments on the matter. I know Leadwerks is firm set in their decision on Newton, I will just see if I can pursue there being a non-physics-at-all branch of the engine for those wishing to do Physics and even Animation via a 3rd party library.

No, if I went posting e-mails around I wouldn't be extended this privileged anymore.

This is wonderful stuff. I can see your work as putting Leadwerks up there as an engine for real-time architecture visualization.

I could be wrong

Yeah, though it is a bit rough since it isn't fully conical, it gives you a really nice approximation. If it is good enough for a camera, it is definitely worth use for AI.

I don't mean to be a jerk, but we had to go through about 15 versions of the engine where joints and vehicles were constantly added and them removed again, so the stability of Newton is highly questionable.

I don't see how you can comment on Havok. ODE, PhysX, and Havok are all based on real physics equations too, they are called iterative solvers.

http://en.wikipedia.org/wiki/Frustum For those too lazy to search.

You can make the box shaped like a frustum...it is a cuboid (i.e. 6 vertices like you can specify for a box) but shaped like a cone. Hence why they use viewing frustums (mistakenly spelled frustrum in American A LOT), for camera viewing.

Politics.

It is set when you call CreateTerrain, you pass a meterspertile parameter.

Download the BMX demo and take a look at the source code to their OpenGL Module, it shows you the meat of the Graphics call, which has its root in C/C++ calls on the Windows API to create a window, setup a context, etc. It basically does what any tutorial on OpenGL basics shows you how to do with regards to a window and context.

C# is known to have an issue when compiler settings are set to Any CPU. You have to compile to either x86 or x64, though since Leadwerks is 32-bit native, it is best to just compile using x86, since you can't really gain anything from x64 using a x86 engine.

The HDR bug can be fixed, but requires GLSL knowledge and some trial and error in the HDR shaders. I couldn't tell you how I fixed it, it just stopped occuring after I messed around a bit.

GetMeshModel does a repeat until parent==nil loop to continuously get the parent until you get the highest level parent of the picked entity. It would be nice to have an engine command like GetMeshModel, or something generic and widely usable like GetRootParent.

I e-mailed the Intel marketing manager who was heading up product management on Larabee, and she said that they were no longer pursuing Larabee as a consumer product, period.

The Jungle movie? Is that the trailer they did for Crysis?

No, I hadn't. I will work that into the condition system.

No, you can have the glory with this one. I am busy rehearsing a speech I have to give in about 16 hours. 5 pages, entirely from memory, and will pretty much determine my English grade. I won't be focused on anything other than it until after school tomorrow, else I would do this shader tonight.

The entity returned by the CameraPick is the actual mesh itself. You have to call GetMeshModel(pick.entity) to get the TModel that actually has the proper keys for it. Since picks occur only to meshes, and not models or physics, you have to get the Model parent of the picked mesh in order to utilize the key system, message system, etc. on a picked entity.

This is nice. It reminds me of the effect when you just stabbed someone in Assassin's Creed I/II and it is glowing into the cut scene; or when you are at the loading screen and it glows and warps into the actual map. +1 from me. Seems like it is a 25% desaturate + all-white bloom.

Lol. So much for everyone having games with shiny balls and lackluster infinite reflections.

I think Josh knows nVidia's hardware and drivers better than nVidia does. Given all the departments they have, I bet half of them don't know their own naming scheme for their cards.

For anyone curious about the current setup: CreateWeapon takes a table that needs to have a .ViewModel string, .Offset vec3, and .Scale vec3. AddAnimation takes a unique name (the ones you see there are what the internal system will be looking for, though I may add the ability to set them custom soon). The second and third parameters are start and end frames. The 4th is a speed modifier, and the last is an optional "one shot" boolean. Things like idle and move are looped, so it defaults to false, but things like reload and fire are done once per state before the state changes. AddSound takes a unique name (the system is designed to play them by frame, but I added WEAPON_DRYFIRE in at the last second along with a weapon:PlaySound(name) command for custom effects not linked to animation), the sound file string location (it handles creating the sound and source), and the frame of animation it should be played at. I basically tried to take the FPS Creator form of setting up guns via their gunspec.txt files, and implement it in a Lua fashion, though my system offers more customization and can be expanded by the user.