Jump to content

Xeonzinc

Members
  • Content Count

    49
  • Joined

  • Last visited

About Xeonzinc

  • Rank
    Advanced Member
  • Birthday 10/17/1987

Profile Information

  • Gender
    Not Telling
  1. HI Wingnut, my 2 cents: The babylon docs taught me a lot about the theory behind shaders and the fragment/vertex scripts etc... I'm now very comfortable working with these. Nasimi produces the ShaderBuilder which produces great results...but I have never attempted to do anything with it because I don't understand the structure of the logic (each individual line makes sense, but how it all fits together?....which I have now learnt is a 'fluent interface'). If you are still looking for the 'cookie-cushion' approach I would suggest we need at least an intro to this fluent way of writing
  2. @ Dal - The idea is exactly the same, you still stand in the middle and then all you need is a really simple vertex shader on top where only y-vertices are set (so really lightweight) based on a heightmap which you offset as the player 'moves'. The heightmaps themselves are passed to the shader in chunks (eventually you could have just one giant height map 10,000+ pixels in size and the code would just pull and pass the right chunks to the shader as needed). Practically all the hard work is done at build time, rather than run time which is one of the changes i was trying to add from your work.
  3. Hi Dal, As i mentioned before I've got a version which does this based on your continuous terrain approach. I've quickly thrown it into a playground- http://www.babylonjs-playground.com/#CEUFD#5 (takes a few seconds to load) A slightly better version: http://www.babylonjs-playground.com/#CEUFD#6 The shading doesn't seem to be right now I've copied it out my project, but if you look at wireframe you can see the edges, and how the seams have been combined. My method for getting vertices was to loop through and define inner/outer vertices when the different segments were being bui
  4. RE: seams I've been working recently on a terrain system using the same theory behind Dal's 'Endless Terrain' from Nov last year. One of the the differences being it allows for non-power of 2 LOD levels, and has varying LOD levels sizes even within the same segment to increase the flexibility. This has meant developing a re-usable method to remove the seams between different LOD levels, which works by essentially duplicating all vertices on both sides of the seam (and with a lot of code....). This is almost in a usable state so should have something to share soon, and could easily feed in
  5. As I'm so keen to use this feature I copied RalphEL's code onto my own fork (a week is a long time ) The blending works really well I was going to try doing a pull request to get it into babylon as RalphEL doesn't seem to have had time to fix the issue you mentioned above, but noticed my pull request would look exactly like his commit (with a tiny bit of formatting). So, being new to github, what is needed to resolve the 159 file issue?
  6. Playground uses the 2.4 alpha, so there will be changes/fixes from the v2.3 you are using. Although I don't know what specific change will be causing your issue.
  7. No problem - I think this is still clone related, so I'll keep it in here: Chains of cloned mesh/skeletons seem to be linked, and starting animations propagates through somehow - see here: http://babylonjs-playground.com/#18U5SO#18 You can use the three beginAnimation lines to start either 1,2 or all 3 of the meshes going at once. All I've managed to figure out is that it's based on the order which the mesh clones are built. For some reason starting animations on rabbit2 also starts rabbit3, but starting rabbit3 does not start rabbit2. Potentially related to the fixes you made above
  8. I'm happy to help where I can, although I feel like I just pop up and highlight mysterious issues rather than offer actual solutions ... maybe I'll understand it all enough one day That said - your fix works great when using the the same skeleton, but breaks down for cloned skeletons (mesh 3 gets the same kind of distortions we were seeing before): http://babylonjs-playground.com/#18U5SO#14 Using my tried and test method of helping.... - Mesh 3 (with the cloned skeleton) doesn't appear to have a _bonesTranformMatrices - The cloned skeleton on mesh 3 has nothin
  9. Thanks guys, yes i was basing my test around those demos, very useful A bit more investigating makes it look like it's not the skeleton cloning, but potentially still the mesh cloning - Wingnut's code adjusted for my mesh has very strange results... http://babylonjs-playground.com/#18U5SO#6 Cloned meshes seems to be distorted when using the same skeleton.....Digging further - manual checking of the two mesh objects shows these differences: 1) _boneTransformMatrices is different between then (same array size, but different values) 2) _poseMatrix is differen
  10. Wow! Super speed bug fixing! The mesh seems to be as expected now I also have a similar issue when cloning a skeleton from the same source (base imported version works fine, but cloned versions are distorted) - I hoped the above might fix it, but no luck. Although I have no idea if that is a rotation problem (no method to make a test playground as bone matrices confuse me...)
  11. Hi, I found this issue when cloning an imported mesh, but it seems to apply to everything: ISSUE: A mesh rotated without the 'Quaternion' system does not have the rotation copied during cloning. See the issue here: http://www.babylonjs-playground.com/#VMRND#1 (the rotate function converts the mesh to Quaternion, but setting rotation does not). I've had a look through the source but didn't manage to find a likely cause.
  12. Interesting topic, so does this mean the skeleton bone envelopes/ranges are stored with the bones, then when the skeleton is applied to any mesh the specific weights for each vertex of the mesh are derived by babylon?
  13. @ Size 60 IE: I get ~50% increase. 21FPS -> 30FPS (stable) Chrome: I get 150-200% increase, 21FPS -> 50-60FPS (varies)
  14. Josh, what kind of performance do you get with your chunk system? Any sign of upper limits on how many dynamic textures can be handled? How would you handle a wide open terrain stretching off into the horizon? Dad72 - I've used worldmonger as the basis for some of my work, given that it uses 4/5 textures and applys them based on GPU to height, if you were applying josh's method in a basic way (to each of the ground textures for each chunk) you would need: 4 (base textures) x 2 (fill & mask for each) x Y chunks = Lots of dynamic textures Although I think that is not a clever way to do
  15. Have a look at this thread, if you haven't already. It's not specifically sprite based but some of the same ideas/methods might apply: http://www.html5gamedevs.com/topic/11601-problem-with-texture-sampling-mode/
×
×
  • Create New...