Michael_J

I've been doing some collision/physics testing today and noticed that SetResponse() does not seem to be working. Setting up two new Collision Types and their response results in no detection (at least based on my tests). Here's a small c++ test app. Please excuse the sloppy code--my brainstorming code is less-than-organized; and snippets don't retain formatting, so it gets even uglier.... Using WASD will move the green box around in space (although it's the other blocks that move, thus keeping your block centered on screen). As it stands, you will get no reaction when the two objects meet. BUT, if you change these lines then things respond as you'd expect: //MEblock->SetCollisionType(Collision::Prop); //<--USING THIS WORKS MEblock->SetCollisionType(50); //<--THIS DOES NOT USING THE ABOVE DEFINITION and //TESTblock->SetCollisionType(Collision::Prop); //<--USING THIS WORKS TESTblock->SetCollisionType(51); //<--THIS DOES NOT USING THE ABOVE DEFINITION Here's the complete .cpp: #include "App.h" using namespace Leadwerks; App::App() : window(NULL), context(NULL), world(NULL), camera(NULL) {} App::~App() { delete world; delete window; }Pivot *cameraDummy, *moveDummy; Light *omnilight; Model *MEblock, *TESTblock, *THEMblock; Shape* Cshape; Vec3 MYmomentum = 0.0, THEIRmomentum = 0.0, MYrotationGLOBAL = 0.0, MYrotationLOCAL = 0.0, THEIRrotation = 0.0, MYvelANGULAR = 0.0;int PREVtime = Time::GetCurrent(); float timeMULTI = 0.0; Vec3 currOMG = 0.0; bool App::Start() { window = Window::Create("test", 0, 0, 1024, 768, Window::Titlebar + Window::Center); context = Context::Create(window); world = World::Create(); world->SetGravity(0, -9.8, 0);cameraDummy = Pivot::Create(); camera = Camera::Create(); camera->SetRange(0.1, 200); camera->SetPosition(0.0, 2.0, -5.0); camera->SetParent(cameraDummy); omnilight = PointLight::Create(); omnilight->SetPosition(0.0, 10.0, -10.0); omnilight->SetRange(20); omnilight->SetShadowMapSize(1024);moveDummy = Pivot::Create(); PhysicsDriver::GetCurrent()->SetCollisionResponse(50, 51, Collision::Collide); //<-- TRYING BOTH METHODS HERE TO SET A RESPONSE -- NEITHER SEEMS TO WORK //Collision::SetResponse(50, 51, 1);MEblock = Model::Box(); MEblock->SetScale(1, 1, 1); MEblock->SetMass(3000); //MEblock->SetCollisionType(Collision::Prop); //<--USING THIS WORKS MEblock->SetCollisionType(50); //<--THIS DOES NOT USING THE ABOVE DEFINITIONMEblock->SetColor(0.0, 1.0, 0.0); Cshape = Shape::Box(0, 0, 0, 0, 0, 0, 1, 1, 1); MEblock->SetShape(Cshape); Cshape->Release(); MEblock->SetPosition(0.0, 0.0, 0.0); MEblock->SetGravityMode(0); TESTblock = Model::Box(); TESTblock->SetScale(0.5, 0.5, 0.5); TESTblock->SetMass(0);//TESTblock->SetCollisionType(Collision::Prop); //<--USING THIS WORKS TESTblock->SetCollisionType(51); //<--THIS DOES NOT USING THE ABOVE DEFINITION TESTblock->SetColor(0.0, 1.0, 0.0); Cshape = Shape::Box(0, 0, 0, 0, 0, 0, 0.5, 0.5, 0.5); TESTblock->SetShape(Cshape); Cshape->Release(); TESTblock->SetPosition(0.0, 0.8, 0.0); TESTblock->SetGravityMode(0); TESTblock->SetParent(MEblock, false); THEMblock = Model::Box(); THEMblock->SetScale(1, 1, 1); THEMblock->SetMass(3000); //THEMblock->SetMass(0); THEMblock->SetCollisionType(Collision::Prop); THEMblock->SetColor(0.0, 1.0, 1.0); Cshape = Shape::Box(0, 0, 0, 0, 0, 0, 1, 1, 1); THEMblock->SetShape(Cshape); Cshape->Release(); THEMblock->SetPosition(2.0, 2.0, 2.0); THEMblock->SetGravityMode(0); THEMblock->SetScale(1.5, 1.5, 1.5); //THEMblock->SetParent(ROOTpiv);return true; } bool App::Loop() { Vec3 offset = 0.0; Vec3 Roffset = 0.0; Vec3 NEWrotation = 0.0;Vec3 OLDrot = THEMblock->GetRotation(true); Vec3 OLDpos = THEMblock->GetPosition(true); int newTime = Time::GetCurrent(); int cycleTime = newTime - PREVtime; if (cycleTime >= 1) { timeMULTI = cycleTime / 1000.0; PREVtime = newTime; if (window->KeyDown(Key::Escape) || window->Closed()) return false; NEWrotation = MEblock->GetRotation(true); //Get my last rotation Roffset = MEblock->GetRotation(false) - MYrotationLOCAL; //Difference between last rotation and current (PROBALBY NOT NEEDED) offset = MEblock->GetPosition(true); //End of last cycle we were set to 0,0,0 -- if we moved then we were bumped, which will affect our momentum MEblock->PhysicsSetPosition(0.0, 0.0, 0.0, 1.0); //Move back to 0,0,0 MYmomentum += (offset * 1); //Adjust my momentum by offset //** Translation ** (WORKING WELL) moveDummy->SetPosition(0.0, 0.0, 0.0, true); //MoveDummy to 0,0,0 moveDummy->SetRotation(NEWrotation, true); //MoveDummy rotation to current rotation if (window->KeyDown(Key::A)) moveDummy->Move(-0.01, 0, 0); //vvv get movements vvv else if (window->KeyDown(Key:)) moveDummy->Move(0.01, 0, 0); if (window->KeyDown(Key::W)) moveDummy->Move(0.0, 0.0, 0.01); else if (window->KeyDown(Key::S)) moveDummy->Move(0.0, 0.0, -0.01); if (window->KeyDown(Key::E)) moveDummy->Move(0.0, 0.01, 0.0); else if (window->KeyDown(Key::C)) moveDummy->Move(0.0, -0.01, 0.0); //^^^ get movements ^^^ MYmomentum += moveDummy->GetPosition(true); //Add new movement to momentum THEMblock->SetVelocity(MYmomentum * -1); //use offset to move other objects //** Rotation ** moveDummy->SetPosition(0.0, 0.0, 0.0, true); moveDummy->SetRotation(NEWrotation, true); if (window->KeyDown(Key::G)) MYvelANGULAR.y += -0.001; else if (window->KeyDown(Key::J)) MYvelANGULAR.y += 0.001; if (window->KeyDown(Key::Y)) MYvelANGULAR.x += 0.001; else if (window->KeyDown(Key::H)) MYvelANGULAR.x += -0.001; if (window->KeyDown(Key::T)) MYvelANGULAR.z += -0.001; else if (window->KeyDown(Key::U)) MYvelANGULAR.z += 0.001; moveDummy->Turn(MYvelANGULAR, false); MYrotationGLOBAL = moveDummy->GetRotation(true); //Record new orientation for use next cycle Quat NewQuat = moveDummy->GetQuaternion(true); cameraDummy->SetRotation(MYrotationGLOBAL, true); //Set Camera orientation with new rotation MEblock->PhysicsSetRotation(NewQuat, 1.0); MYrotationLOCAL = moveDummy->GetRotation(false); //Probably not needed } //Continue Time::Update(); world->Update(); world->Render();context->SetColor(255, 0, 0); context->SetBlendMode(Blend::Alpha); context->DrawText("UPS: " + String(Time::UPS()), 2, 2); context->DrawText("My A VEL X: " + String(MYvelANGULAR.x), 2, 15); context->DrawText("My A VEL Y: " + String(MYvelANGULAR.y), 2, 30); context->DrawText("My A VEL Z: " + String(MYvelANGULAR.z), 2, 45); context->DrawText("My RoffSet X: " + String(Roffset.x), 2, 75); context->DrawText("My RoffSet Y: " + String(Roffset.y), 2, 90); context->DrawText("My RoffSet Z: " + String(Roffset.z), 2, 105);context->DrawText("My Rotation X: " + String(MYrotationGLOBAL.x), 2, 135); context->DrawText("My Rotation Y: " + String(MYrotationGLOBAL.y), 2, 150); context->DrawText("My Rotation Z: " + String(MYrotationGLOBAL.z), 2, 165); context->SetBlendMode(Blend::Solid); context->SetColor(0, 0, 0); context->Sync(false); return true; } Thanks for giving this a look. If there's something wrong with my setup then please feel free to slap me upside the head I thought maybe I had to register the collision types before created the response, but I couldn't find anything seemed appropriate. Based on a couple other threads though, I was under the impression I didn't need to do that. Hence, this appears to be a bug... Note, I also tried using PhysicsDriver::GetCurrent()->SetCollisionResponse() with the same results...

That clears things up a bit--never actually had time to investigate WHY EOF wasn't defined. Good to know...

The quick answer--you can add this to the appropriate .h file before including fstream: const char EOF = -1; EOF is defined (IIRC) in stdio.h as -1, but if you're not including that then you can define it yourself...

ABSOLUTELY nothing fancy here--just a quick shot showing a very basic Noesis GUI implementation. It was fairly quick and painless thanks to bandrewk's wrapper (and some quick responses to a few questions this morning ). I also had to give myself a pretty quick course in XAML to get up to speed, but I think I've got the basics down (Noesis has some pretty nice tuts over on their site that helped a lot). Now I just need to add functionality to make it DO something Anyway, here's a shot

Just a short video showing functional ship systems, and various views all synced up, thus allowing for proper Newtonian free-flight.

Nice round of updates, Josh. Well done...

I believe the culprit is the GetOmega() command using local space. Setting an Omega in local space with a constant value seems to work fine...

Pretty simple bug to duplicate, really. If you get an object's current Omega, and then set the Omega using that same value in Global space the object in question rotates as expected--at a constant speed. However, if you try to do that same using the object's Local Space then the object's rotation quickly spins wildly out of control, with the Omega value flip-flopping from positive to negative. Here's a simple test app you can try. Please excuse the less-than-elegant code, I'm in the middle of testing a few things and my brain-storming code is NOT pretty... WASD will move the green square around. If it bumps into another surface, or if you add rotation with T and Y, the blue square's rotation goes nuts. However, if you change the GetOmega and SetOmega commands to TRUE (for global space) then everything works as expected... ALSO, if you set to true and tap T or Y to start a rotation you'll see the cube eventually slow it's rotation until it stops. Obviously there's some form of drag going on (probably so the object can eventually go to sleep). Is there a way to alter this so an object rotates/moves indefinitely (as an object would in space)? If not I'll find a way to over ride that behavior, but a command to do it would be more elegant. (By the way, the object in question does not use gravity and is floating "in mid air", so surface to surface friction doesn't apply ) Thanks #include "App.h" using namespace Leadwerks; App::App() : window(NULL), context(NULL), world(NULL), camera(NULL) {} App::~App() { delete world; delete window; } Pivot* Dummy; Pivot* ROOTpiv; Light* omnilight; Model* Tsurface; Model* elevator; Model* character; Shape* Cshape; float hvalue = 0.6; Vec3 horiforce = 0.0, ROTforce = 0.0; Vec3 Turnit = 0.0; Model* wallA; Model* wallB; bool App::Start() { window = Window::Create("test", 0, 0, 1024, 768, Window::Titlebar + Window::Center); context = Context::Create(window); world = World::Create(); camera = Camera::Create(); camera->SetRange(0.1, 200); camera->SetPosition(0, 2, -5); world->SetGravity(0, -100, 0); Dummy = Pivot::Create(); omnilight = PointLight::Create(); omnilight->SetPosition(0, 10, -10); omnilight->SetRange(20); omnilight->SetShadowMapSize(1024); Tsurface = Model::Box(); Tsurface->SetMass(20000000); Tsurface->SetCollisionType(Collision::Scene); Tsurface->SetColor(1.0, 0.0, 1.0); Cshape = Shape::Box(0, 0, 0, 0, 0, 0, 1, 1, 1); Tsurface->SetShape(Cshape); Cshape->Release(); Tsurface->SetScale(20, 0.5, 20); Tsurface->SetPosition(0, -2, 0); Tsurface->SetFriction(0, 0); Tsurface->SetGravityMode(0); wallA = Model::Box(); wallA->SetScale(1, 1, 1); wallA->SetMass(30); //wallA->SetMass(0); wallA->SetCollisionType(Collision::Prop); wallA->SetColor(0.0, 1.0, 0.0); Cshape = Shape::Box(0, 0, 0, 0, 0, 0, 1, 1, 1); wallA->SetShape(Cshape); Cshape->Release(); wallA->SetPosition(0, 0, 0); wallA->SetGravityMode(0); camera->SetParent(wallA); wallB = Model::Box(); wallB->SetScale(1, 1, 1); wallB->SetMass(30); //wallB->SetMass(0); wallB->SetCollisionType(Collision::Prop); wallB->SetColor(0.0, 1.0, 1.0); Cshape = Shape::Box(0, 0, 0, 0, 0, 0, 1, 1, 1); wallB->SetShape(Cshape); Cshape->Release(); wallB->SetPosition(2, 2, 2); wallB->SetGravityMode(1); wallB->SetScale(3, 3, 3); return true; } bool App::Loop() { if (window->KeyDown(Key::Escape) || window->Closed()) return false; Vec3 offset = 0.0; Vec3 Roffset = 0.0; Vec3 currOMG = 0.0; offset = wallA->GetPosition(true); Roffset = wallA->GetRotation(true); currOMG = wallA->GetOmega(false); //<<<< CHANGE THIS TO TRUE FOR GLOBAL FOR CORRECT RESPONSE std::cout << currOMG.y << "start" << endl; wallA->PhysicsSetPosition(0, 0, 0, 0.5); Dummy->SetPosition(0, 0, 0); Dummy->SetRotation(Roffset, true); if (window->KeyDown(Key::A)) Dummy->Move(0.01, 0, 0); else if (window->KeyDown(Key:)) Dummy->Move(-0.01, 0, 0); if (window->KeyDown(Key::W)) Dummy->Move(0.0, 0.0, -0.01); else if (window->KeyDown(Key::S)) Dummy->Move(0.0, 0.0, 0.01); if (window->KeyDown(Key::E)) Dummy->Move(0.0, -0.01, 0.0); else if (window->KeyDown(Key::C)) Dummy->Move(0.0, 0.01, 0.0); Turnit = 0.0; if (window->KeyDown(Key::T)) Turnit.y += 0.100; else if (window->KeyDown(Key::Y)) Turnit.y -= 0.100; currOMG += Turnit; Vec3 NewPOS = Dummy->GetPosition(true); horiforce += (NewPOS + (offset * -1.0)); wallB->SetVelocity(horiforce); Tsurface->SetVelocity(horiforce); wallA->SetOmega(currOMG, false); //<<<< CHANGE THIS TO TRUE FOR GLOBAL FOR CORRECT RESPONSE std::cout << currOMG.y << "end" << endl; //Continue Time::Update(); world->Update(); world->Render(); context->SetColor(255, 0, 0); context->SetBlendMode(Blend::Alpha); context->DrawText("UPS: " + String(Time::UPS()), 2, 2); context->SetBlendMode(Blend::Solid); context->SetColor(0, 0, 0); context->Sync(false); return true; }

Yeah, console writing will slow things down, but that's a steady, constant hit. This was absolutely system pauses when moving the mouse quickly. AMD also had an issue with this a year or so ago, but that was fixed with a driver update. Whatever, I'm just happy I found the problem, and also pretty happy it wasn't an issue with either my code nor with Le 3.1

Yeah, I tried that fix and it didn't work for me (but at least it confirmed the issue ). Not saying it doesn't work, just didn't on my system...

I DID find the cause of this and it's a very real issue for a lot of people. There's two reasons actually: The first is a virus that you can find in your processes list with the name stij.exe Removal is easy (one of many videos here: ) as long as you get all of it so it doesn't come back. MY issue though was Windows 8.1 and my high performance gaming mouse. As I understand it, M$ set the mouse poll rate down to 125 for Win8.1 from Win7's 1000. What this did was cause any high performance mouse with DPI's in the thousand's to basically "flood" the system with any fast motion inputs. In a small Le test app I went from 1000 UPS down to *2* (yes, two). You have three options here: 1) buy a cheap, low poll-rate mouse 2) set Win8.1's poll rate back up to 1000 through some method I wasn't 100% comfortable with. 3) If you're fortunate (as I was) your high performance mouse comes with software to allow you to lower the poll rate. My Logitech did. Setting it down to 500 helped. 250 helped even more, and at 125 everything is now as smooth as glass Anyway, I just wanted to report back on this to say that this wasn't an Le issue, but it is real and I wanted to pass on the info if anyone else has a similar problem. Thanks

Well, there are definitely instances where you want the emitter to continue when off-screen. Two simple examples of this are missile exhaust trails and aircraft engine condensation trails. You'd want these types of emitters to ALWAYS emit no matter what so that you get the nice, long, trails that you'd expect without gaps, or the trail starting over when they came back in view. Typically, as you suggest, you have a setting that allows you to state if an emitter functions when off screen. Personally, I'd find this implementation to be satisfactory with the assumption the default value would be as the system functions now.... Just my two-cents

Yeah, I few readilyl visible glitches further down in the document, but otherwise this is looking good. Thanks

Just an update on this. My sound designer tested a version of RogSys locally on his machine with the same results (with his nVidia as opposed to my AMD). Without "Steam_appid.txt" in his main RogSys folder and Steam running he gets the out of vid mem error. Once he exits Steam completely all is well... I also had him add my copy of "Steam_appid.txt" and try running WITH Steam open--as expected that too worked, but he got the Steam overlay. So, it's not a local issue and we'll need some sort of fix so we can release outside of the Steam environment... Thanks Edit: And, just to note, I'm not calling Steamworks::Initialize() anywhere within RogSys...

Just a quick vid mainly to show the completion of the Leadwerks 3.1 engine integration. All the key elements that were in the old engine are back, except for the system displays (which will come from Noesis). Next up is Noesis integration

Shadmar, your solution works fine unless you have a foreground object that has some material alpha set. If it does you will see the background behind it. This is fine if you're looking through a window, but not if you're looking at an object that's intended to be solid but is using alpha for another purpose (setting a shader value, etc) I THINK what you want to try to do here is use the foreground's depth buffer as the alpha mask for the foreground (not sure--just a guess)?

Physics are fine here (c++ version to clarify). I do notice a bit of a frame hit if the updated character controller gets hung up on something; but otherwise all is well... Not saying you DON'T have an issue--I just can't verify...

A project created with 3.1 (LUA or C++) currently must have the Steam DLL inlcluded, regardless if you plan to ship on Steam or not; but, Steam is NOT required to run said project. You should be able to compile without the Steam lib so that the dll need not be included (as bandrewk was suggesting). Edit: Regardless though, I don't really care if Steam dll is required or not. MY issue is that the method for not having the Steam overlay show up, as described by Josh, is to remove Steam_appid.txt from the game directory. This works; but in doing so, when I run my prog and Steam is running in the background then I get the Out of Video Memory error. The error is the part that needs to be fixed

Josh--I know you just closed this as you believe it a "Steam issue"; but, after reading through the entire thread you linked to in the original post ( http://steamcommunity.com/app/221040/discussions/0/828934089859605401/ ) I see nothing there that confirms this as a problem with Steam. In fact, on the last page it was an update from Capcom for RE6 that fixed the issue. Assuming this isn't local (which I don't believe it to be but it's certainly possible), I'll make the case again that if a game created using Le 3.1 is not released on Steam it needs to be Steam independent. It shouldn't matter if Steam is running in the background or not, nor if Steam_appid.txt is in the game directory or not.... Again, thanks... (Also, sorry for the new thread, but you locked the other before I had a chance to respond)... Original bug-post text: "Already mentioned this to Josh a couple weeks ago--making a reminder post for him... I discovered that if I have Steam open and try to run RogSys with no Steam_appid.txt in the main game directory (as if the user did not purchase the game from Steam), I will get an Out of Video Memory error at start-up. At this point the engine shuts down the app. If I run RogSys with Steam closed and no .txt file, or if I run it with Steam open and the Steam_appid.txt file in the main game directory, then all is well. I didn't notice this at first until I started adding some serious art to the scene and using some higher res shadow maps. I would imagine that not everyone will release their titles on Steam, and for me it's likely the Windows version of RogSys will not be on Steam (at least initially); so this would need to be addressed at some point. Le3.1 Standard, c++, running outside of the editor Thanks... Edit: Just to mention--my r9 290 has 3 gigs on board. I highly doubt I've thrown that much game art at it yet"

That's looking very nice so far. I'd offer two pieces of advice: 1) Things have a tendency to "feel" more real if they have some reason or purpose (rather than just being there because "they look cool". "Cool" art doesn't always translate into a believable environment. 2) Doing detailed work normally goes more smoothly and efficiently if you have some concept art to work from. What I typically do is sketch out an idea; model a VERY rough, low-res version of it; take it into photoshop and paint a detailed concept piece. Then I use that and further develop the rough model I built. The rough model will quickly let you know if your 2D sketch actually works in 3D (so you don't waste a lot of time finding out otherwise). Mainly though--practice, practice, practice. You'll learn something new with every piece you build.... And, thanks

Already mentioned this to Josh a couple weeks ago--making a reminder post for him... I discovered that if I have Steam open and try to run RogSys with no Steam_appid.txt in the main game directory (as if the user did not purchase the game from Steam), I will get an Out of Video Memory error at start-up. At this point the engine shuts down the app. If I run RogSys with Steam closed and no .txt file, or if I run it with Steam open and the Steam_appid.txt file in the main game directory, then all is well. I didn't notice this at first until I started adding some serious art to the scene and using some higher res shadow maps. I would imagine that not everyone will release their titles on Steam, and for me it's likely the Windows version of RogSys will not be on Steam (at least initially); so this would need to be addressed at some point. Le3.1 Standard, c++, running outside of the editor Thanks... Edit: Just to mention--my r9 290 has 3 gigs on board. I highly doubt I've thrown that much game art at it yet

Cheers, BES. Nice work from you, too... Believe me--I know what you're talking about Some days nothing ever seems to go right. About all you can do is, as Dude suggested, keep yourself motivated and just press on.

My CC is already in a physics hook, so I never noticed if this was the case; but it's certainly possible and does make sense if he (Josh) was referring to LUA and its UpdatePhysics(). However, it was my understanding (which obviously could be wrong) that as physics is run on its own thread the timing and timing adjustments were handled for you regardless (60 FPS). I am new to the engine so I'll defer to the more experienced here

Rick, that would depend on how you're doing your timing, I think. For example (and I'm SURE you know all this but I'm going to explain for someone who might not), EVERYTHING is normally done "per second". So, if I only updated once per second then I'd multiply everything by a value of 1.0 to get the full effect. If, I suddenly started updating at 2 FPS, or 500 ms per frame, then I'd multiply everything by 0.5 so that the full value is applied over the course of a second. 60 FPS would give a multiplier of 0.01667 ((1000 / 60) / 1000). In case you're wondering, there's 1000 milliseconds per second, hence the use of that number (again, explaining for someone who may not know). Using this method, then, a value greater than 1.0 SHOULD be impossible unless you're doing less than 1 FPS (in which case there's some other issues you should be addressing first ). Now, what I CAN imagine is that maybe GetSpeed() is giving a multiplier based on some fixed FPS (60 maybe?). If that were the case then I could see how values above 1.0 would be easy to get back from it. If true then I wouldn't consider GetSpeed() useless or broken, only specific. For those that don't know, if you want a down and dirty method for getting a speed multiplier that is NOT FPS specific, you'd do: Diff = Current Clock Time - Previous Clock Time Multi = 1000/Diff Multi *= 0.001 (or Multi /= 1000 -- if you prefer) (record current time as previous for use next cycle) You'll want to use Leadwerks' method for getting clock time (Time::GetCurrent() ) because it handles "pausing" for you when you use Pause() and Resume(). As Josh has said though, when using physics (including the character controller) you DON'T want to adjust for timing as it is handled for you.

Just did a QUICK triple head display test at 5760x1080. I was averaging about 70FPS, which I don't think is too shabby considering the optimizations both Josh and I want to do respectively. I didn't set a proper FOV so the side displays are stretched a bit. Later, I plan on a proper implementation with 3 cameras (one for each display) that can be independently adjusted. Here's a lower res shot of the test though--this one taken from within the cockpit looking back at the closed entry hatch: