• Content Count

  • 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, given that it ends up so different to anything else in Babylon currently (I think the wikipedia link on fluent language tells people what they don't know, but doesn't really support teaching it). What would also help me (and I hope others) is some detail of how all of this feeds back to the vertex/fragment shader mindset. Put simply I don't currently see how to convert my vertex/fragment logic into shaderbuilder logic.
  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. The main limitation of this specific 'treadmill' terrain (ignoring getting everything else to work with it) is the limit of textures you can store in the shader at once, so I think your visible range is effectively limited to 2x your shader texture chunk size (probably 2k or 4k pixels). On the other side with a fully chunk based system you avoid this issue, but the downsides I see are much less flexibility over the LOD/graduation and higher number of draw calls (unless you can get good performance merging/unmerging as needed). I can't see either way being perfect in all situations, so maybe we will end up with a few different systems to be used in different circumstances ...Or perhaps eventually we will get to "The One Terrain System" and everyone's lives will be simple and carefree....
  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 built. You can see the code, but it's quite long, so ask for any more info
  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 into a chunk based system. (also agree with josh/Dal on the example above, it must be the heightmap data if the vertices are perfectly aligned). Does anyone have a robust 'chunking' terrain system we could add the LOD onto? With the right system is should just be a case of replacing 'createGroundFromHeightMap' with a version of the new function i'm creating. It sounds like what you have Josh may be similar that, although we are replacing the same function so may need to merge them somehow!
  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 nothing in it's _meshesWithPoseMatrix (the other skeleton has the other two meshes as expected) - The cloned skeleton on mesh 3 has a very different _transformMatrices (which actually looks similar to the _bonesTransformMatrices on the other two meshes....) My attempt to make swap around a _transformMatrices with a _bonesTransformMatrices in the babylon source has resulted in a very different error, so I will leave it here...
  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 different between then... 3) cloned mesh has a undefined _rotationQuaternion: where as base does not 4) base mesh has undefined _waitingActions: while clone does not Does any of this ring alarms? Or am I just highlighting expected differences between meshes
  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 it. A much better might be to keep worldmonger as it is, but adopt Josh's code to add a chunk system ontop (so you have 4 tiled textures for worldmonger, and then lots of chunk textures not tiled). It would only need a small re-write of the worldmonger ground shader in order to draw the chunk textures on top of the existing worldmonger logic where alpha is visible. It would be interesting to know how many chunks can be handled in this way
  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/