• Content count

  • Joined

  • Last visited

Community Reputation

467 Neutral

About TeaTreeTim

  • Rank

Personal Information

  • Interests
  1. Hoverboard Version 4

    With a gun turret showing hot spot targeting. The thumbpad/trackpad on the controller targets the turret. It plays out a bit like jousting because its hard to keep focused on a target when moving.
  2. Hi, Here is my latest hoverboard design for those that like to DIY. Physical features: Uses the Vive controllers as the handles and trackers. It moves around like a joystick using the bicycle suspension spring in the picture. This spring system also allows for easy pack away. The attachments are agricultural water tank fittings that have been machined to fit. Engine features: Pitch accelerates and also the trigger acts as a throttle. For physics I use slip and slide against terrain with reflection off plants (think pin ball machine). Things I've learnt doing this: Keep the board you stand on flat, its too hard to balance with the eye wear on. Vive controller orientation is critical so you need some kind of alignment system like the white plastic on the top of the pole. Turning is based on controller roll and yaw. Don't allow your physics to spin the board or it will turn into a vomit comet.
  3. Full Body VR Control

    I used to use Kinect but it is not compatible with Vive so I have shelved it. It was decent for its time and I would love an updated version that can work with Vive. It's not just the physical signal, there is some kind of clash between services. I have made a few variations of hoverboards like the attached image. Originally I didnt have handles, used a joystick controller to give tilt and the player held the vive controllers. Its too hard to balance when you cant see so handles with joystick buttons and a Vive tracker is better. The tracker is better than a joystick as it is tracked positionaly as well as giving tilt response. I will make a seat next having made a tilting recumbent bicycle before. It will be the same principle but use arduino and electric motors to control tilt so you lean to turn etc. I'd say before smell and taste a more urgent requirement is standardisation in different input systems like I describe. Most current VR games seem to only support vendor controls and an open API for supporting different vehicle types for example would be awesome. As opposed to normal PC games where a game might support keyboard/mouse, joystick and XBox controller, a VR game needs a new suite of controllers that includes support for haptics. If anyone is interested in an open API project to offer a standard template for this I can contribute. As for reading brainwaves etc that's great but probably more a question for academics looking for a thesis topic.
  4. Its easy to do a lunar landscape, julia, perlin simplex, diamond square whatever. The hard part is dealing with water. If the terrain is not self aware (ie a super map that spans entire continents) then how do you know if the river is going downhill all the way to the sea? The pic is my current work is a compromise with a swizzled Julia template and simplex style hills (I need the skate park look because I use a VR hoverboard). I deal with rivers by having everything at ground zero, flat earth. The below UAV height map is generated by compute as the camera moves around. Splat maps and content are also generated. In reality its not linear scale like that but the further out the further apart the points are (torus grid). I've done height map with overhangs by the way, there's no rule that says you cant displace non vertically you just need to deal with collisions. Beyond just pure height map generation, its really more about content generation. Who cares about miles and miles of the same stuff. We want roads and towns etc. How do you path roads? What type of content can you randomly generate? I generate roads after the fact and do road works following a pathing algorithm that tries to not go up or down. Notice the contradiction here because I just said I don't do that for water but rivers can go for unknown distances and don't make sense if they die out or hit a dead end. Doesn't matter with roads, just put something there. All I have at the moment are points of interest, I don't actually create villages yet just the roadworks to them so that's as much as I can say.
  5. Should be opposite:     struct PatchOutputType { float edges[3] : SV_TessFactor; float inside : SV_InsideTessFactor; };     PatchOutputType ExamplePatchFunction(InputPatch<HullInputVertice, 3> input) { PatchOutputType output;   output.edges[2] = FactorFromPoints(input[0].pos.xy, input[1].pos.xy); output.edges[0] = FactorFromPoints(input[1].pos.xy, input[2].pos.xy); output.edges[1] = FactorFromPoints(input[0].pos.xy, input[2].pos.xy); output.inside = FactorFromPoints((input[0].pos.xy + input[1].pos.xy + input[2].pos.xy) / 3.0f);   return output; }  
  6. Since that example (1-3) deliberately eliminates axes with low weights, it might be best to test and not sample if weight is 0. I don't know why they allude to this and not do it in the sample code.
  7. Tessellated ocean with no culling artifacts.

    What depth buffer format are you using? I'd try again with higher precision. 
  8. Tessellated ocean with no culling artifacts.

    Why wouldn't backfaces appear in wireframe. Do you mean you are using culling CW or CCW in the shader or that even in solid they show? What do you mean 'even well above ocean surface'?
  9. I do it like this: http://www.socoso.com.au/Tiogra/Index.html?page=basemesh.html A combination of torus and tesselation. Tesselation has its limits as to how much and it also has other issues, such as the triangular orientation inherent in the system. It is also not magically faster, more triangles still means more resources to render. It is very good for monolithic grids where you have areas that need more detail (such as rocky parts).
  10. If everyone ran from what they didn't like no games will ever get made.   Even if you love programming and enjoy puzzle solving, when you do programming for a living there is going to be a point where you will come to hate it; if only briefly. What will you do at this point, abandon your dreams just because you don't like programming?   What about the Indie developers who dream of making there own games, yet they hate programming and can't afford to hire a programmer, should they give up?   I think the point is games aren't just about programming. Not everyone is suited to programming and just at a person to person level, you are welcome to do something you don't like but if you are more suited to model design, you'd be better off doing that and making some money on turbosquid etc. One day someone might commission you for a game.
  11. So just to go over the basic points: - You are confident the matrix gm_Matrices[MATRIX_WORLD_VIEW_PROJECTION] is updated every frame correctly (no silly error in the camera class)? - You confident this is a UV coordinate issue and not for example vertices moving or a depth buffer problem? - You don't have any hardware extras turned on in the Catalyst utility, particularly relating to anti-aliasing? - You are confident this has nothing to do with the reflection mapping you seem to be doing? Edit: and have you tried turning down vsync and matching the frame rate in catalyst if it lets you?
  12. You know you have to set the constant buffer and apply it to a slot for the shader? Show that code if you are already doing it.
  13. Realization of displacement mapping

    What is the displacement for? If you are generating terrain then choice of normal is a big deal because you can end up with collisions. I talk about it a bit here: http://www.socoso.com.au/Tiogra/Index.html?page=Displacement/normals.html I talk specifically about my engine so it's not all generic.   As for division, tessellation does the heavy lifting for you if you are prepared to commit. For pregenerated terrain, I used to use quad tree terrain with a displacement algorithm but that was part CPU part GPU, you might be able to do it all in compute these days I don't know.
  14. Assimp and Skinning transforms

    There's a lot of things that can go wrong. Start with the basics like is the mesh scaled and rotated the same as the armature at identity and are the bone heads where you expect them to be?
  15. Have you tried using b instead of cb?      cbuffer Standard : register(b0)    {        };