Naughty Alien

..im not sure, are we talking about 'infinite' terrain here or actually, several different terrains??

..climb angle you can easy get from the example i have posted..its that simple, and it can be applied to all controllers you have on scene..it should be straightforward..

@YouGroove As i said before, tessellation is nice thing but doesn't really feel necessary for characters if your game running on latest hardware, as characters could look already very very good, without any dynamic altering such as tessellation. On other side, if you aiming older hardware, you may enter serious trouble by using hw tessellation as from the GPU manufacturers standpoint, for mentioned hardware, such feature is not uniform and chances are that your game will not work at all on some configurations. I don't see any reason to prove anything as people in industry already have had first touch and feeling with given option (tessellation), and it appear to be unnecessary (The Witcher 3 team)..anyway, this discussion seems to fade away from original thread topic, in to endless talk, and thats not good for any of us, so maybe is time to put a 'dot' on to this one

..hahahah..this guy really sounds like a yoda... is it same voice actor?

..that would be interesting indeed .. on side note, while does look attractive, tessellation is not a 'silver bullet' of optimization..if we are talking about triangles manipulation, what tessellation is basically about, modern hardware already have large enough vertex buffers, that properly modelled and very good looking characters can be loaded and utilized without any LOD basically, so there is no real benefit of using tessellation at all on modern hardware, except potential issues , as The Witcher 3 team clearly said and ditched tessellation out exactly because of mentioned problems. Its just not really needed on new hardware and causing more issues than its worth. In case you want your game to be backward compatible and playable, then thats a ultimate reason why would you forget about tessellation at all..it will kill frame rate in a heartbeat, if you somehow, manage to get it work on wide variety of hardware setups..so, my personal conclusion is..its cool option to have, but getting rather useless with massive vertex buffers modern hardware is equipped with.. Exactly same reasons why The Witcher3 team, kicked tessellation out of scope.. http://www.examiner.com/article/the-witcher-3-developer-explains-lack-of-tessellation-on-pc-ps4-and-xbox-one

..something like this will do ..

@YouGroove Im confident LE3 can do it just fine, and with Octree like representation of game world, related to LOD, it can be very fast and efficient..i dont see reason why it shouldnt work with Leadwerks 3..

@GameCreator It works exactly like that..curvature is determined based on vertices alignement/direction so when edge is calculated, mantioned parameters are used to determine where set of new triangle vertices will be positioned. Thats why tesselated box doesnt get curved, while number of triangles can be rather huge, simply because offset angle between largest edges is zero.. Of course, with tesselation is always good to use displacement maps for best results, but personally, Ill never ever use it for LOD, considering current situation with GPU hardware manufacturers..

..tessellation is not something you could call 'new'..its with us since DX9 time and perfectly doable in DX9, as well as documented..basically, whole tessellation process could be fit in to : 1) Select Triangle 2) Choose the largest edge of triangle 3) Bifurcate the selected largest edge 4) Now you have two triangles 5) Repeat until bored to death So its nothing really new and it exists quite some time. ATI/nVidia/Intel chipset and what not, doesnt agree very well about particular technique, what eventually complicating execution on engine side, so, in order to maintain backward/hardware compatibility, much as its possible, I wouldn't put my bet on to hw tessellation..

..if im developing game, with system that doesnt support LOD, i will do simple octree like structure made out of bounding boxes, slicing down my game world. Bounding boxes will be same size (fixed size), and their setup will happen during loading, after entity with its LOD are loaded. During loading time, each entity will be checked in order to determine in which bounding space they residing initially. And thats all. During run time, it will be returned current bounding space camera is in, and based on that will be known links to surrounding bounding spaces. Then simply flip specific LOD generation based on which bounding box of entity with LOD is occupied, related to camera bounding space. So, you can set LOD to work in such a way that respond to hierarchy 'distance' of linked bounding spaces, related to camera bounding space and entity bounding space. Closer to root(camera bounding space), better quality LOD. Its very very fast and works perfect. I used similar system for Hoodwink, and something like that for new game we are working on (loads of enemies, forming patterns, etc)..

@Guppy Are ya a lawyer or something?

..well..i cant say as i do not have new incarnation of LE tools, but i guess, if shaders are supported and they are, then its a matter of creating 2nd UV layer in your lightmapping tool and baking lightmap and later just sticking lightmap to corresponding UV layer inside your code trough shader ..

3D lightmaps would be a best way..your character/dynamic object could be shaded/shadowed by static geometry (lightmapped) on the same way real time lights works..incredibly fast and visually, no real time light solution could beat up prerendered GI lightmaps. But you have to have, non movable lights on lightmapped geometry..

..why would you do such transformations every frame ? Such system require that NPC class, does that only when NPC moves, or inside camera sight, and then then update itself, what is not processing heavy at all, then store its transformed screen space coordinates. All it takes is to read it and simple > or < comparisons to determine is specific entity inside rectangle. Its much much faster than 3D bounding space calculation check against every single entity..not to mention that most probably, he will have to use oriented bounding space if he really want acceptable accuracy of detection, and that goes much more expensive for check..

..i will not create any form of 3D box..instead Ill use just 2D rectangle you have already created, and project entity pivot points (position) in to 2D screen space and check that against rectangle you have already made..much much faster and way better accuracy..

..what is the reason for such versions based on programing language of choice..i don't understand that..

..i would do that trough game logic, where specific kind of attack will produce output result(s) such as push back..same should apply on to main character where such motion caused by AI action, affect player as well..

Okayyy

Shere in that picture looks like a creation of collision hull, and sphere is a bad choice for collision body check. Considering that shape of majority of geometry primitives, especially custom one, fit in to a sphere leaving huge gaps on sides, yet colliding with everything around, makes sphere not really best choice. Ever try to fit your character in to sphere and use it as I collider? There is nothing to be convinced with spheres. They have its place in game dev, but that place doesnt carry badge of ultimate collision check body. And regarding whole talk about collision checks and math behind, in AAA games I was able to study code from, there is a tons of nasty clever tricks used for all sorts of checks, and square root and similar checks are rare as dinosaurs today..only here and there some remaining of it. Its just my opinion based on what I saw and experianced on consoles as they are not as forgiving as pc is when we talk development. All this things I mentioned, really matter in that hardware poorer environment. So whatever you see works on pc, doesnt necessarly means that works same on consoles.

@YouGroove ..i'm not trying to prove you wrong or anything like that, but i just think you misunderstanding how whole thing works, as math you writing doesn't mean much considering fact that physics cycles are independent from renderer and independent from logic cycles...this is where is trouble with accuracy, not in math behind trajectory/distance calculations..also, square root is a thing you will avoid at any cost in your loops.. Another trouble is physics engine used itself. If you really want your code to be elegant and easy to port, you will NEVER EVER create fundamental part of your game play, entirely dependent on to any particular development tool API, in this case physics, because in case of porting and been forced to utilize entirely different physics engine, that will be actually, rewrite of entire code base, attached to particular physics engine, and even worse, output results may look different as different engine is used and you entirely rely on it. I have seen it myself between Newton and Bullet, as well as Havok (trial)..practically, entire API for game is changed and hardly will look identical..it is advisable to write your game code, at least part what does matter, any API agnostic, much as possible, and ultimatively, that will give elegant solution of bullet issue, discussed on this topic..

..reason why you dont want physics engine to deal with this is called Frame Rate vs. Object Speed. There is no physics engine, fixed this issue yet. Its basically number of moments in time per second when physics is calculated. Each frame is treated as separate from all other frames, and the space between frames is not calculated. A low framerate and a small fast-moving object leads to a situation where the object does not move smoothly through space but in fact seems to teleport from one point in space to the next point in space as each frame is calculated. At sufficiently high speeds a projectile will miss a target, if the target is small enough to fit in the gap between the calculated frames of the fast moving projectile. So, the most viable way is to calculate trajectory what will fit within non calculated frames, and use raycast to check objects for collision, once that particular frame is calculated with new position. Thats what AAA games using most of the time. One i know 100% is ratchet and Clank as i have full source of entire game as well as Uncharted.

..i will not rely on to physics for this kind of things, especially once frame rate start to be variable..

..for short range bullets, Ill go with raycasting, as you could assume that bullet goes in straight line trajectory in near instant time..for long range shots, ill use physics or calculated curved path of projectile, where projectile will still use raycasting, every time new position/alignment on calculated curve is updated..

Thanks for response guys. Just to clarify my question, I have to say that I was talking about Leadwerks 3.1, not current version targeted for mobile devices. I have zero interest in current setup, however, 3.1 is something I may think about, provided that its not locking me down to LE editor of any kind, and giving me a freedom to build my geometry in 3dsmax and c++ only, for win, osx, linux. So pipeline you guys describing is current version or you have access to some alpha or beta version of 3.1 version, so you know details?

...so LE 3.1 is something like, complete desktop version of LE 2.x (Win, OSX, Linux) ? If so, is it tied (modeling wise) to geometry builted with provided editor, or it can work in similar/same way as LE2.x (general purpose geometry file formats used FBX, etc) ? Programming wise, is it forcing programmer to use Lua only or it can be entirely used C++ without any Lua code ? If so, how compilation is done for individual targets (I have to rewrite C++ code or modify it for certain target or..) ?