Jump to content

Tim Shea

Members
  • Content Count

    44
  • Joined

  • Last visited

Community Reputation

15 Good

About Tim Shea

  • Rank
    Advanced Member

Profile Information

  • Gender
    Male
  • Location
    Sacramento
  • Interests
    AI, Game Development, Cognitive Modeling
  1. Tim Shea

    Mini map

    If you aren't using a GUI framework, you can use a plane with texture coordinates to accomplish this. Any decent framework will have this option though. Leadwerks has a graphics engine, but no GUI functions built in, so you have to decide how to accomplish that.
  2. Probably. I think the Math::Curve function does the same kind of thing. I just never noticed that function, so I rolled my own.
  3. Tim Shea

    Mini map

    This is a good idea. The diffuse map from a terrain could be a good source as well. You definitely don't want a second view, since the minimap is not a view into your real time scene, it's just a component of your GUI.
  4. No, you can't make the model a child of the pivot, because it will inherit all those little bounces from its parent. You have to manually copy the smoothed transform. My position code is sort of complicated because of some other objects, but this is how I smooth the camera orientation. Variables prefixed with an m are member variables. // Calculate the mouse movement Vec3 center = Vec3(context->GetWidth() * 0.5, context->GetHeight() * 0.5, 0); Vec3 delta = Vec3(window->GetMousePosition().y - center.y, window->GetMousePosition().x - center.x, 0) * mLookSpeed; mAngularVelocity = delta * mSpringFactor + mAngularVelocity * (1 - mSpringFactor); mOrientation += mAngularVelocity; mOrientation.x = Math::Clamp(mOrientation.x, -mPitchRange, mPitchRange); mCamera->SetRotation(mOrientation + mAngularOffset);
  5. Tim Shea

    Mini map

    I have never played a game with a fully rendered minimap. That would be jarring I think. What you typically would want is just a sprite pane in your GUI system, with icons for each of the objects you're interested in, and a prerendered (probably stylized) image for the static map.
  6. If you watch the value of the y coordinate for your character controller, you'll see that it is bouncing very slightly on the ground. This is common for many physics engines, although most will have a damping property that can reduce the effect if it's undesirable. Since we don't have a damping property, we can implement our own by using a pivot for the actual character controller and then applying a smoothed transform to the model. Obviously, the model should then have no physics shape itself. You will have to play with the smoothing factors, but it is possible to have a perfectly smooth first person or third person controller in Leadwerks. For my characters, I'm smoothing both the character controller motion and the camera offset, because the mouse pitch bypasses the character and can cause unappealing stutter as well. Edit: In fact, on a more general note, smoothing out just about any parameter will tend to give nicer looking results, from physics to animations to sound. In real life, everything happens over time, so things that occur without any transition in games tend to stand out.
  7. I think buildings (and dynamic obstacles which do not themselves navigate) are intended to use the Prop collision type. Props should not affect the NavMesh, but they are dynamically handled when generating paths (at least, this is my understanding). I also would love to see the navmesh and character controller fleshed out (or even just exposed so they can be overridden) but given what you have to work with I think your best option is to manually avoid assigning destinations inside dynamic obstacles, and then just use the baked navmesh. Collisions between units are always an issue with A* pathfinding. You can google for some interesting solutions, e.g. crowd steering, but it isn't something that can really be addressed in the pathfinding algorithm itself.
  8. I can't comment so much on the rendering aspect, but this week I was doing some profiling for the Wings project and I was able to get about 20 animated characters on screen, all with real time AI, perceptions, full physics, navigation, etc. at around 70 FPS on my laptop (nVidia 620m). This was an encouraging result for me, since we haven't even begun to profile in detail or really optimize. I haven't tried to push it to the upper limit.
  9. Are you sure it's done that way is commercial games? Because I think if you just draw a line it's going to look wonky with a uniform thickness. As far as I can see from a quick search, it is not a line: https://www.google.com/search?q=resident+evil+laser+sight&espv=210&es_sm=122&source=lnms&tbm=isch&sa=X&ei=zaT3UsW-HY_poASa3YLADg&ved=0CAkQ_AUoAQ&biw=1360&bih=643#q=resident+evil+laser+sight&tbm=isch&imgdii=_ It has diminishing thickness, and a sort of noisy transparent texture applied.
  10. Make sure you also include all the preprocessor definitions: WINDOWS;WIN32;OS_WINDOWS;PLATFORM_WINDOWS;DEBUG;_DEBUG;OPENGL;_WIN_32_VER; _NEWTON_USE_LIB;_LIB;_NEWTON_STATIC_LIB;DG_USE_NORMAL_PRIORITY_THREAD; %(PreprocessorDefinitions)
  11. You don't have to link the dependency into your library, you just have to set the headers correctly. The end user of your library then links your .lib and any of its dependencies. We are currently using this techniques successfully for the Wings project on both 3.0 and 3.1.
  12. There was some debate later in the thread about whether this was necessary. I'm not sure what the final decision was. In the event it doesn't get added, you could probably throw some JSON into a property and then use a parser if you have a complex format.
  13. Switching to static didn't fix it, so I tried looking at the shaders. I noticed that the issue only occurred with the diffuse+normal shader, not with the diffuse only, so I started playing with my normal maps. I'm not sure if the .tex files were somehow corrupted or what, but opening each of the normal maps and re-saving them fixed it. Thanks! I kept fiddling with settings but didn't think to try the textures themselves.
  14. This problem has been bugging me for a while, and nothing I can find seems to fix it. The illumination from all the point lights in my scene seems to be skewed to one side of the actual light. I have tried adjusting the range and spot light direction settings, to no avail. I've also seen old references to a point light shadow offset property, but I can't find this in the editor. The two screens show basically default settings (only diffuse color modified). I can replicate the issue with a brand new point light as well. In the first image, the light is clearly skewed to the left. In the second one, the skew is different on one surface than another. The scene has no directional lights, just ambient and point. Does anyone have an idea how to resolve this?
  15. Unfortunately this isn't something that can be done "very basic" and from scratch. There are several, moderately complex components involved in developing almost any kind of three dimensional character control scheme. Think of it like cooking, prepackaged stuff will make it easy, but has to hide some of the detail.
×
×
  • Create New...