Jump to content

Michael_J

Members
  • Posts

    202
  • Joined

  • Last visited

Everything posted by Michael_J

  1. Ah, I see. I never thought to fire it off as a post to generate the maps. Thanks for sharing. Makes perfect sense now that I think about it...
  2. Well done. I was planning on doing this for my planetary shaders as an optimization, but I haven't yet had time to investigate it. Any tips on getting the process to render to a buffer to get me started (if you don't mind my asking)? Regardless, looks great...
  3. Yes, this seems to be occurring after one of the most recent updates (not sure if it was the last or one before--they came in pretty quick succession). Yeah, you have to force Steam closed and then you can start Leadwerks again.
  4. confirmed here--I get a crash, too, just about the same moment I get the "please close first" message.
  5. Might I suggest adding a mode to the sprites that will allow them to billboard AND roll so that they are always upright relative to the camera. For example, right now if the camera rolls 180 degrees the sprite will appear to be upside down. For a particle such as smoke or something this isn't too big a deal. But if you're displaying text on the sprite then it becomes an issue.
  6. Hmm--not sure I agree there. For example, let's say I'm developing a shader and I code something that causes a crash when it tries to compile (has happened to me a couple times). Now, when I go to re-open the editor it WON'T open because of the bugged shader. Isn't that's like saying Visual Studio shouldn't open because you accidentally coded a crash bug? The only way I got out of this situation was because I had an earlier version of the shader source-controlled and could fall back to it. (Or, yes, I could have changed the shader extension so it wouldn't try to load). In any case, as far as I can tell, all the other shaders are working fine...
  7. I have no idea--as far as *I* know, nothing.... I'm just telling you what I did to correct the problem based on what the log file pointed to, which was the vertex portion of the sprite.shader The bigger concern should probably be why the editor failed as it did simply because the shader failed to compile....
  8. I replaced that sprite.shader with one from another project and all is well now. I sent you a pm with the vertex shader portion in code so you can have a look.
  9. Here's what it gives me: Syncing Addons... Initializing... Initializing OpenGL4 graphics driver... OpenGL version 431 GLSL version 430 Device: AMD Radeon R9 200 Series Loading texture "D:/DCI_work/Rogue_System/Materials/Common/bfn.tex"... Loading shader "D:/DCI_work/Rogue_System/Shaders/Editor/terraintool.shader"... Loading shader "D:/DCI_work/Rogue_System/Shaders/Editor/wireframe.shader"... Loading shader "D:/DCI_work/Rogue_System/Shaders/Editor/solid.shader"... Loading shader "D:/DCI_work/Rogue_System/Shaders/Model/default.shader"... Loading shader "D:/DCI_work/Rogue_System/Shaders/Editor/grid.shader"... Loading shader "D:/DCI_work/Rogue_System/Shaders/Lighting/ambientlight.shader"... Loading font "C:/Windows/Fonts/Arial.ttf"... Loading shader "D:/DCI_work/Rogue_System/Shaders/Drawing/drawtext.shader"... Loading shader "D:/DCI_work/Rogue_System/Shaders/Drawing/drawprimitive.shader"... Loading shader "D:/DCI_work/Rogue_System/Shaders/Editor/skybox.shader"... Loading shader "D:/DCI_work/Rogue_System/Shaders/Misc/occlusionquery.shader"... Loading shader "D:/DCI_work/Rogue_System/Shaders/Model/Shadow/shadow.shader"... Loading shader "D:/DCI_work/Rogue_System/Shaders/Lighting/directionallight.shader"... Loading material "D:/DCI_work/Rogue_System/Materials/Icons/directionallight.mat"... Loading shader "D:/DCI_work/Rogue_System/shaders/editor/sprite.shader"... Vertex shader failed to compile with the following errors: ERROR: 0:30: error(#314) No such field in interface block viewmatrix ERROR: 0:30: error(#145) Left of "[" is not of type array, matrix, or vector: entity ERROR: 0:30: error(#160) Cannot convert from: "unknown qualifier interface block" to: "highp 4X4 matrix of mat4" ERROR: error(#273) 3 compilation errors. No code generated Failed to compile vertex shader. Error: Failed to compile vertex shader. Assert failed.
  10. Where does the log normally get saved? The last time I used the editor I had the message log hidden, and now I can't expose it as the Assert Failed dialog prevents it...
  11. Just a head's up--after tonight's update from the beta branch I get an "assert failed" message as soon as the editor opens. It still shows "Leadwerks Editor - <untitled>" in the title, so I don't even think it starts to load the last level loaded before the Assert Failed. Clicking "OK" immediately shuts down the editor...
  12. WELL DONE, Josh. Yes, building proper collision geo is one of those things that HAS to be done, and is actually somewhat of an art in itself to make these models both efficient AND representative of the visual model. ANYTHING that helps the artist out in this area is a big plus!
  13. A new RogSys vid--was in the shader frame-of-mind after the planetary work, so I did a bit on the Viewport Monitor System. This isn't all that it does, but should give you an idea:
  14. I'd suggest maybe a nice specular map to give it scratches and nicks, but yes--looks good...
  15. The culmination of my initial celestial art pass: Might take a couple days before moving on to the next task to check out this whole Oculus Rift "thing"
  16. Starting to integrate one of the many new planet/moon surface shades I've been hacking away at for the past couple of weeks. Lots of work to do still, but good enough for a first pass...
  17. Right now the shader uniform "currenttime" is ONLY updated when some action is performed in the material editor viewport (rotate material ball or zoom in/out, for example), or when you save a shader. This makes it somewhat tedious when trying to create/editor animated shaders. It would be great if currenttime was constantly updated, at least where the material editor is concerned. Thanks... edit: (and yes, I know the main viewport has a realtime render option--just saying it would be nice if the material editor has this as well )
  18. Thanks Josh. I was JUST about to start working on my own sprite manager, so this addition comes at a great time. Looking forward to some basic documentation for it
  19. Yeah, I figured that's what was going on. Out of curiosity, I believe Newton allows for collision detection without updating physics (using this thread as a basis for this assumption: http://newtondynamics.com/forum/viewtopic.php?f=9&t=4475&p=36406&hilit=+collision+only+#p36406). Is this possible via Leadwerks integration? I mean I know I could set my on collision responses with type trigger and use the callback; but does this cause only the collision to be updated via NewtonCollisionUpdate() instead of calling NewtonUpdate() (which updates collision AND physics)? If not, could a bool flag for "collisions only" be added to Leadwerks::World? http://newtondynamics.com/wiki/index.php5?title=NewtonCollisionUpdate From remarks: " This function shall be used ONLY when Newton is used as a standalone collision library. Use NewtonUpdate if you are also using rigid body dynamics" Thanks...
  20. Character collision is MUCH improved now. Well done...
  21. I've been doing a lot of testing the past few days with physics objects and collisions, especially in the case of a physics parent ( mass > 0 ) with children with a collision type but mass == 0. This effectively creates a rigid union of two or more collision objects. One of the reason for this is that I've had no luck thus far creating "rigid" joints between physics objects that have no spring-like effects. Beyond that, in many cases I don't need the overhead of a joint for a simple union. So, I thought I'd post my findings in case they might be of use for someone else. Here's what I came up with (collision reactions in all these cases assume valid collision types and responses have been set up) : 1) A parent physics object can collide with another parent 2) A parent and its children can have different collision types 3) If a parent has a collision type in which no responses allow for a physics reaction (Collision::Collide) then no reactions will occur EVEN IF the children have types and responses that allow for it 4) Children of one parent can only detect other parent objects, but NOT their children 5) Children with a Collision::Trigger response will detect ALL parent objects, EVEN THEIR OWN, if the collision types allow for a detection So, let's say you had a chair made up of multiple objects. The "root" object has both collision and mass (allowing physics motion), while the children only have collision. Now, if you picked this chair up and threw it against a wall it would react properly--bouncing off the wall and falling to the floor; but ONLY if the walls and floor were one parent object (or each their own parent). If the walls were a child of the floor then only the chair's root object would collide with them, but all pieces would collide with the floor. Being separate pieces though, you could then do things like detaching all the children when it first hit the wall and giving each a mass; thus making a breakable chair. Your results may vary I suppose, but this is what I've found to be true, after a LOT of testing, when setting things up like this. By the way, if anyone knows a way to make a "rigid" physics joint (no spring-like motion when collisions occur) I'd be happy to learn
  22. Thanks. This post can be deleted. I found the issue--was a copy/paste oversight on my part. Sorry for the false alarm...
  23. I tested the above code by copying it back and it works fine now in both release and debug. again, sorry about the bugs created by the copy/paste.... WASD will make the blue block move left/right/forward/back. The E and C keys will move it up and down. At least it does here, anyway No collisions will occur until you change the two relevant lines (thus ignoring the attempted SetResponse )
  24. Ah--was some copy/paste weirdness. Let's try this again: #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 DEFINITION MEblock->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; }
×
×
  • Create New...