Naughty Alien

..i guess controller is always aligned along gravity vector, so in that case proposed solution will work, provided that parameters are taken along direction controller is facing..

...nobody said it cant be done..i haven't seen a one post saying that..but I will be more than happy to see a game spreading from latest modern hardware down to hardware just 3-4 years old (as a developer, you should care about this, unless you are Crytek or Epic and pushing up high end stuff), and using tessellation across all hardware setups (not just nVidia)..it was never question is it doable or not or does it exist..DX9 can do it just fine and its well documented in DX9 SDK, so its already how long?? 10 years? There is a reason why mentioned technique is not become a 'standard' yet, even exist for some time, and reason is NOT is it doable or not, but hardware mess, manufacturers created, what makes your code rather difficult to deal with all that, hence, making your code probably crash on some configurations...thats all...if you want to run your game on latest hardware, go for it by all means..if you want to hit much wider audience, you will not go with tessellation.. @Rick My apologize, if my contribution here caused confusion, as your question was rather simple. In order to make it simple, much as i can and know, Ill tell you this. Do not trust a word i have said. Maybe take it as a some sort of remark or warning, if you please. I suggest, you try yourself mentioned techniques, and see for yourself what will do best, and how your code will perform and then make up your mind based on personal evidence you will collect trough such process. I have done similar things few years ago, and that was basis of my claims here. I may be wrong, of course, as my knowledge about matter is limited, but i do understand principle behind it. Do yourself favor, and test it yourself, as entire this thread is turning it to a confusion. All best bro..cheers..

..simple way to determine memory pressure based on textures.. RGB Compressed DXT1 0.5 bpp (bytes/pixel) RGBA Compressed DXT5 1 bpp RGB 16bit 2 bpp RGB 24bit 3 bpp Alpha 8bit 1 bpp RGBA 16bit 2 bpp RGBA 32bit 4 bpp To figure out total texture size: width * height * bpp. Add 33% if you have Mipmaps. ..as for triangles..Geforce 6600 can do 375 million vertices per second(provided that no texture or anything is loaded),and its VERY old card, and as you can see, there is more than enough triangle space, far more than you can have with textures..

Rick, it wouldnt affect speed at same rate simply because you will share same texture/materials, over same model..vertices are cheapest thing to keep in memory...test it yourself..load in to any engine, one single large mesh, let say, 150K triangles, no texture of any kind attached to it..record frame rate..now, exit and load identical mesh but this time, with texture attached to it..look at frame rate now..it will be noticeably lower..vertices are cheapest to deal with, and long as your LOD meshes share same texture/material, speed impact will be minimal...heavy memory load is related to textures in memory, not really vertices..however, processing vertices(due amount), can impact performance, but classic LOD if you need it, doesnt really do that so it will be for sure, faster on not so modern hardware than any tessellation processing...on modern hardware however, as stated before, you really don't need LOD, relatively speaking, to amount of characters you will have seen at once..

..tessellation is no magic and rather simple process, yet it can be time GPU time consuming..there is no doubt that it can be used, but fundamental question is, do you really need it when modern hardware can crunch triangles necessary for good looking model with ease..it is truth that in such scenario, use of tessellation would be downsampling, in order to get less triangles to render..however, having in mind that modern hardware have huge vertex buffers, capable to store enormous amount of vertices, so, tessellation is really not a necessary option to have really even if you want to downsample your character mesh..point is, if you have not so many characters on scene, and using modern hardware, you really dont need any tessellation as LOD on mentioned characters..if you have plenty of characters (eg. 100), in order to keep your performance up, you will most probably rely on instancing in order to populate such amount of characters(same skeletal/mesh with different textures), rather than have tessellation over every single character..other people in some AAA ranked studios, realized that and I dont understand whats the problem here..i see tessellation well used over static geometry, but not at all on animated characters (if we talking modern hardware).. If game need to be executed on modern and not so modern hardware, and far as im, as a developer concerned, I want that,,in that case, use of tessellation is no go for both, characters as well as geometry, because chances are, it will not work on plenty configurations or it will be very slow..all in all..its nice and not worth trouble you may get yourself involved..simple as it is..

..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..