Michael_J

Thanks Aggror. I'm using 3.1's c++ project template...

In that tutorial there are no lights created. Sorry, I should have mentioned in my post that I tried disabling both lighting for the camera and physics for the world with no help. If this is not a local issue to me then hopefully there's some issue Josh can track down using this tutorial code that will help smooth things out. Hence, I need someone to confirm my findings....

Could someone confirm this so we can find out if it's local or not, please? Using the tutorial found here (I'm using c++): http://www.leadwerks.com/werkspace/page/tutorials_legacy/_/making-a-first-person-camera-r15 To prepare, do two things: Comment out this line: window->HideMouse(); Add this line just before context->Sync(true): cout << Time::UPS() << endl; Compile and run. Do you notice two things--a spiking of the mouse pointer, and a drop in frame rate from 60 (vsync'ed) to about 30-ish as you rotate the camera? It seems to get worse as you rotate faster. It's very noticeable if you turn vsync off: context->Sync(false). For me, I go from the 300's with drops down into double digits. I've seen this type of thing before in engines, but only when video memory was being offloaded to system memory. I can't imagine this would be happening though for a scene with two textured boxes... What it does do though is make the character controller, in this example, very choppy when you look around... I don't care what the consensus is, I just need to know if it's a local issue or something that Josh may need to take a look at So, either way, thanks in advance for the confirmation.

Really, joints aren't the way to do this. What's really needed, and Josh has talked about finishing up support for at some point, are Convex Decomposition collision shapes. What this does is take an object that has concave elements (your table top and columns, for example) and creates a collision mesh made out of a number of convex elements. Newton has support for this, and you can see in the headers where Josh already has a framework for it. There are other physics properties I'd like to see exposed so we have even more control over objects (or at least a method to get the physics world and Newton bodies so we can access Newton directly, but this not the proper way to do it as it could interfer with the Newton wrapper).

Absolutely--rendering rear view mirrors and such to a texture, and then displaying that on geometry in the main view, is how it's done. Trust me--I've worked on racing simulators since 2005

No, sadly--as I said, the friction value, 0.0 or otherwise, doesn't seem to matter....

No worries. Thanks for trying @gamecreator -- thanks, I'll have a search...

Yeah, still slowing to a stop. There certainly seems to be some sort of resistance at work here...

Thanks. I'll give it a test in a bit...

I tried both with the same result actually. Sorry, should have mentioned that...

From the testing I've done over the past couple of days, it seems that if I apply a force to an object that does not use gravity (regardless of the friction value) the object will eventually come to a stop. My only conclusion is that there is a global drag or other resistance occurring that is causing this (or some other form of forced restitution perhaps?). If this is the case is there any way to change this on either a global or per-object level (per-object preferably)? In the environment I'm working in (space) once an object is in motion it should remain in motion until something interferes with it, of course. Hence, I need to alter this behavior... Thanks...

Yeah, sorry--forgot to mention EnableLimits(); No problem at all

I also just found that you get some very interesting results if some objects in the chain use gravity and others do not...

I was just working on this today and chatted with Josh a bit about it. You can still parent the objects together, but to create the physical connect, yes, a joint has to be used. When two objects are jointed together they do not collide with each other--normal operation there as the physics engine see's them as the same body. Use the joint's SetLimits() so that the objects don't penetrate each other... if you: joint->SetLimits(0, 0) then there will be no rotation around the pin (in the case of a hinge), hence creating a "weld", if you will. I HAVE noticed that both objects need to be the same mass. If one object's mass is greater than another you will get a spring-like effect at the joint location. Finally, if any objects in the chain (either parent or objects jointed to it) has their mass set to 0.0 then the entire "body" will be excluded from physics updates. ALL objects need a mass...

Yeah, that's exactly what I saw. I just don't think that's what people expect at first. Perhaps worth a mention in the documentation?

I was doing collision and physics work yesterday and experimented a lot with PhysicsSetPosition. I believe I now understand its behavior and what may be causing people problems when trying to use it. When you use this command to manually move an object from point A to point B a velocity vector is calculated to make this transformation in the physics world. The strength is just a multiplier as to how fast you want to get there--entering a value of 1.0 will fully cover this distance in one frame. The "problem" comes in on the next frame. The velocity that was added is not nulled out, so the object just continues along in the same direction. Probably the perceived functionality of this command is that the object would get to point B and just stop there. My first attempt to handle this was (in pseudo code): if (wantingTOmove){ object->grab current velocity object->PhysicsSetPosition object->set old velocity } The problem here is that by setting the old velocity, in the physics world it effectively cancels the PhysicsSetPosition and the object didn't move at all. My next attempt was: if (wantingTOmove){ object->grab current velocity object->PhysicsSetPosition object->UpdatePhysics() object->set old velocity } I was hoping UpdatePhysics() would force the object to update to the new position, but this didn't work (so my use of the method was incorrect). My next attempt was successful: if (!objectForcedmove){ if (wantingTOmove){ object->grab current velocity object->PhysicsSetPosition objectForcedmove = true } } else{ object->set old velocity objectForcedmove = false } What this does is use a Boolean flag that will allow you to move the object on one frame, and then set the old velocity on the next. At this point the object behaved as expected: if the old velocity was 0,0,0 then when the object got to the new location it just stopped there. Now here are my questions: 1. Is this the correct behavior for PhysicsSetPosition (and I assume PhysicsSetRotation), or is it not working as intended? 2. If it is the intended implementation, can a new version of the command be added that will handle this "behind the scenes"? 3. If not, is there a way to force an additional physics update on an object mid-frame so this can all be done in one pass (probably not as the physics runs on its own thread, yes?)? 4. Finally, if using this command makes the object non-collidable (as it seems to--I witnessed my object penetrating walls to get to the new location), then if you had to manually update an object every frame wouldn't it effectively nullify the object to physical collision and reaction? If so then I'd warn people NOT to use it and a rigid body for trying to make their own character controller, as I've seen some mention of. Rather, if you need a RB then you'd probably be better off calculating the required velocity yourself from A to B and applying it to the object via SetVelocity() so as not to interrupt the physics simulation (seems the better way to go?).... Anyway, long post I know. I just thought the information I found might help out others who may be having trouble dealing with this command. Cheers...

Yeah, understood. I was just wondering if there was a list available in the event I needed to set up some special case. But yes, it looks like your predefined types cover the majority of cases. Thanks.

When using SetCollisionResponse() the third value seems to reflect the type of response. From what I gather 0=none and 1=collide with physical reaction Question is: are there any other types that can be set? For example, is there a "collide with no reaction" response, etc?

"Recalculating the normals corrected it, but also destroyed the geometry." Yeah, it totally worked to correct the lighting, but the geometry was all over the place. It's certainly not a bug with Le--simply some vertex oddness when exporting from MAX. I've seen it before, but never on an entire object. Completely recoverable though so I wanted to be sure to post the info...

I had this happen to me yesterday. I exported an object from MAX via fbx and imported it into the editor--it was completely black regardless of the material I applied to it--definitely a lighting issue caused by invalid normals. Recalculating the normals corrected it, but also destroyed the geometry. To fix this, I exported from MAX as an .obj, deleted the original object (after making a backup of course) and re-imported the obj. The obj format has been known to "clean" vertex errors that can develop in a MAX scene over time. When I exported the "clean" version of the object all was well. Just posting this here in case anyone else ever encounters a similar issue...

Now have ship exteriors loading and instantiating. Primary elements of a pre-Alpha station exterior with diffuse-only shader: Next up: collision setup...

I'll be pre-ordering my DK2 next month some time. Hopefully there won't be any MORE dev kits to buy before they release the thing

Posting this as a reminder for Josh: While using exceptionally high-resolution cascading shadow maps (4096 x 4096) with Light quality set to 2, my prog closes with a "GL_Out of Memory Error" on the second frame IF Steam is running in the background. Closing Steam completely resolves the issue. Verified this on 4 separate occasions... I have an AMD R9 200 with 3 gigs on it, so plenty of vid mem to go around in theory...

Cheers for the confirmation...

Slowly starting to get things on screen. This is a hangar interior (lots of missing geo not yet exported thus causing holes and inconsistent shadow mapping) with a diffuse-only shader and a single light source: