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. 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. 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,
  5. 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
  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
  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. I
  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...