Jump to content

Michael_J

Members
  • Posts

    202
  • Joined

  • Last visited

Posts posted by Michael_J

  1. Unless I missed a method that already does this...

     

    It would be great to have something to tell how many monitors are in use, the current resolution of each, and which monitor to open the window on.

     

    I know this info can be found using various windows methods, but something native (so the support is available for Windows, Linux, with C++ and LUA) would be appreciated, I think...

     

    Thanks...

  2. I tried just adding the .dll's--didn't work for me. I just included the installed in a "Utilities" folder if needed (which obviously doesn't help in your case). Yeah, was just planning on having the installer do it once I have one set up...

  3. This isn't exactly a bug, so I thought it be better to post here. I was wondering if there was a more graceful way to handle when someone tries to run a Le-based program using a card that does not support OpenGL 4.0. Right now, at least for RogSys' testers, they simply get a crash. Is it possible to put up a message similar to what you do when OpenAL can't be found?

     

    Just curious--thanks :)

    • Upvote 1
  4. 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...

  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.

    • Upvote 2
  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. smile.png (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. 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.
    

  8. 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 :) )

    • Upvote 2
  9. 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...

  10. 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 smile.png

×
×
  • Create New...