Josh

The character controller uses my own physics routines which have been very stable. I can't say what the problem might be without seeing an example.

You are attempting to make worlds bigger than what 32-bit floating points can handle. The only solution is to make it smaller.

Interesting modification.

Well, I guess Newton is not officially compatible with Android yet. I have PhysX for Android, Windows, and Mac, but the iOS version is not released yet. Newton going open source is not a good sign, because it means if you have a problem, you have to fix it yourself. I know Bullet won this poll, but I think it would be the worst option of the three: Open source (=bad documentation and support), no corporate marketing campaign to convince people it's the best, and I am not familiar with it. It's a tough call because PhysX means restricting the world size below what we have now, but my guess is people would rather have it, even if it's full of bugs, just because it has a nice logo. Upper left at 0:07: I guess I'd better start talking about THE AMAZING POWER OF PHYSX 3 since AFAIK Leadwerks will be the only major engine using the new version.

I think you are thinking of STALKER, they called it a "rain shadowmap". That's just it, you do a depth render to a texture, then use that in the shader to tell where the rain is allowed.

You just get the world position and normal of each pixel, round off to the nearest XZ direction (there are four possible). Use that for the vertical component of rain sliding down. Then add in raindrops based on the Y component of the normal. You can do something similar for snow accumulation...someone posted a video of it working.

It's possible to do this with a post-processing shader that perturbs the normals using an animated texture and a calculation of the surface normal.

Thanks for releasing this!

I think what happens is, by the time you have coded to that level, it's beyond the ability of new users to do anything with it. Instead of modifying and using your beautiful code, they will just end up asking for a lot of features to be added, and then you're coding someone else's game for them. That's why I am trying to make the new engine have a lot of high-level functionality built-in. On top of that, you have the issue that 3 or 4 main languages are being used by the community, and any language you target will only be relevant to a fraction of the users.

One thing that really surprised me when I started with 3D was how unusable most of the free 3D stuff on the internet was. I had no idea how much more care it took to produce good real-time 3D models.

This is a very Zen-like question.

The entity type will be terrain, but we should add something like a vegetation index so you can tell better.

Try this: http://www.leadwerks.com/werkspace/page/Documentation/le2/_/tutorials/rendering-lights-r384

Some of the colors seem way too neon, but then some of the ground textures have really nice and sharp details. I'd like to see more of this.

Yep, we just store color in the unused fourth column of the entity's 4x4 matrix when it's sent to the GPU.

I won't promise that because you might have the android version you can use yourself by then, but I am certainly interested in testing performance.

It might be difficult to separate the renderer from the rest of the engine. It might be possible to do this once, but I would not want to continually update it with features I add to the engine. We compiled for android with no code changes needed, so I think you will find it builds pretty easily for ps3 or whatever else. I can't say for sure, but it's on four operating systems already.

You'd get a TOUCH_UP event with index 1 (it starts with 0) and know the second finger left. The next finger down would become the second, because that would be the first empty slot.

I had a little fun with iMovie with this one. Don't be a hater.

I've implemented multitouch input on iOS, and gave Aria the information he needs to do the same for Android devices. Multitouch is an interesting input method. Each "touch" has a beginning, some movement, and an end. To handle multiple touches, they need to be persistent; you need to keep track of which touch is which. This is a little weird if you're coming from a mouse and keyboard paradigm. On iOS, you have a pointer to a UITouch object, and on Android it's a jObject object (I think). I opted to make touches correspond to fingers...the first touch is touch 0, the second is 1, and so on. I set it to handle up to five touch inputs simultaneously. (Interestingly, there doesn't seem to be any limit on the number of touches a device can handle at once. At least, I tried ten, and ran out of fingers to test any further.) Touches emit an event which you can get through the event queue, or you can supply an event callback hook. Alternatively, you can just call GetTouchDown(), GetTouchHit(), GetTouchX(), etc., which work the same as mouse input. The only difference is you need to supply an index for the finger number. To implement zooming, I just checked to see if finger 0 and 1 are touched, then found the distance between the two fingers. I'll have to write some detailed tutorials about this, but until then here's my code: while (PeekEvent()) { Event event = WaitEvent(); Print(event.Debug()); switch (event.id) { case EVENT_KEY_DOWN: if ((event.data)==KEY_ESCAPE) { return false; } break; case EVENT_WINDOW_CLOSE: if (window==event.source) return false; break; case EVENT_TOUCH_UP: numTouches--; break; case EVENT_TOUCH_DOWN: numTouches++; Print("Event.data = "+String(event.data)); Print("Event.X = "+String(event.x)); Print("Event.Y = "+String(event.y)); Print(""); touchposition[event.data].x = event.x; touchposition[event.data].y = event.y; dx = touchposition[0].x - touchposition[1].x; dy = touchposition[0].y - touchposition[1].y; touchdistance = sqrt(dx*dx+dy*dy); break; case EVENT_TOUCH_MOVE: if (event.data==0) { if (numTouches==3) camera->Move(-(event.x - touchposition[0].x)*0.01,(event.y - touchposition[0].y)*0.01,0); touchposition[0].x = event.x; touchposition[0].y = event.y; dx = touchposition[0].x - touchposition[1].x; dy = touchposition[0].y - touchposition[1].y; d = sqrt(dx*dx+dy*dy); if (numTouches==2) camera->Move(0,0,-(touchdistance - d)*0.01); touchdistance = d; //Print(touchdistance); } if (event.data==1) { touchposition[1].x = event.x; touchposition[1].y = event.y; dx = touchposition[0].x - touchposition[1].x; dy = touchposition[0].y - touchposition[1].y; d = sqrt(dx*dx+dy*dy); if (numTouches==2) camera->Move(0,0,-(touchdistance - d)*0.01); touchdistance = d; // Print(touchdistance); } break; } } And here's the result in action:

The first object that happens to be in the list, which is random, will be turned first. However, both will be called before the UpdateWorld() functions exits, so when rendering occurs they will both have the same progress completed.

If you want to enable terrain shadows, just call EntityShadowMode() with the terrain entity.

I can't tell. My HTC Evo is capped at 30 FPS and gets 7-16 FPS with 14,000 ploys. My iPhone gets 60 FPS with the same, the max framerate. I think this is going to vary wildly depending on hardware.

I didn't set out to to that, but I can't think of any reason different platforms would have any trouble communicating over a network. Kind of scary that you could play on your cell phone against someone on their PC. I'll have to look closer at how network communication works on mobile devices.

idk!