Naughty Alien

..hi guys..i just need to test this over various platforms, and ill appreciate if you confirm that everythings working just fine...just click on to ground and see is it working pathfind+animation..also leave it in idle (no pathfinding) for a 20 seconds in order to see side idles automatically trigerred...I need to know is it working or not..thank you in advance.. here is download link http://www.easy-share.com/1912022762/CNA.exe

..if you know that upcoming PS4 is fully compatible with PS3 code and that basic introduction will be more powerful GPU with more shader pipes then now (28), then I think nothing to lose with development cycle for it..as for Xbox360, I assure you, you will not see nothing new in next 2 years for that matter, rather than small upgrades..

..reason why i was asking is initial talks on forum, about V3.0 as a completely new system, oriented to be cross platform in its essence, including Mac/Linux as well as consoles, out of box, instead of just PC, so after i saw features set exposed, with no mentioning about cross platform compatibility, including Linux or Mac, i wanted to know whats actually going to be like V3.0, apart from VFX exposed, what are actually doable in current versions with some workarounds (im not sure about terrain, never used it, but other stuff is doable)..and eventually if cross platform compatibility is not planned for first release, are there such plans for Linux/Mac in some reasonable future, when we talking about V3.0 ? My interest in growth of this engine in correct direction is very big due fact that 2 of my games using it, so my concern/questions are reasonable, and my personal/professional growth require also other horizons on sight than PC, and thats why V3.0 growth is something I need to know more about. I know there is at least 2-3 guys more here, whos seriously working on their games and similar questions, most probably rolling trough their heads. I really think real LE 'arena' and playground should be heavy consoles or if not at begining, Linux/Mac.

..i assume those features are PC based..is there anything on sight for cross platform compatibility , and im not talking about phones but Xbox360/PS3, this next gen engine should be actually suitable for ? Just curious..

..well, as I said, not all output navmesh shape is rectangular, and way trough door doesnt require more than 2 major nodes..also, it almost doesnt make sense to populate nodes just about 1 meter away from each other, unless its small tiny space, what is okay, because its small ..and even then as I said, each floor can have its own nodes grid generated (not connected to others), so search is performed at actual area what is much faster than one bigger nodes grid..second thing is that actual walkable nodes are generated over navmesh without considering crates or other obstacles eventually appear , so such check is done over path returned , and when critical node is reach, just new path search is performed to avoid that small obstacle (faster than calculate everything from start point)..thats something i do, but everyone can have different way of doing things..I have seen some commercial games and nodes populated for pathfind in them and its really not that high density..its actually quite low..thats why I wanted to see some benchmark test, if any..

..i found out that more than 3900 searchable nodes are more than enough on my levels (considering distance between nodes approx 10 meters) its about 625x625 meters area..but even that is sometimes not necessary, if path is NOT as a rectangle shape, what is most of the time case, so i noticed, generator extract roughly up to 1000 nodes max, for custom shape levels whats very nice and handy for search algo..also, its possible to have independent groups of search nodes in order to release pressure from search routine, so it can be search by zones..all this tests are a bit confusing for me because im getting quite nice results, and i dont feel comfortable when i see no obstacle..thats why I wanted to try something out there, considered very fast, as a benchmark..

..i have seen this..both versions are slower than mine so im looking some sort of 'pro' test proggy, if i may call it that way..

..im looking for some decent example (EXE) of A-star, in order to properly benchmark small lib i have made for Tutorial lessons of mine..do you guys know any similar program, executable, that i can download and set some conditions (eg. number of nodes to search, start/end node..), in order to do proper benchmarking, speed wise.. everything i found is slower than my lil lib, but i dont want to accept that as a final, since many of them are java applets and they are suckers, on other some seems to be very basic form of A-star with no optimizations, so i really cant take those as a valid reference..im looking for something considered very fast..if you know any, please, post download link so i can take it and do some tests before release lessons..thanks in advance guys..

.. i heavily doubt this, therefore, it must be a one of the reasons why editor doesnt have any Lua editor worth something..

..it seems somebody didnt get kiss from mommy, before sleep

..LE is a fine system, and i can highly recommend it...dont be discouraged with low network support simply because, you can plug in, any available network solution and get desired results of your choice..finest moments of LE you as a programmer will feel is a freedom to code way you like it..from game itself, up to tools of your own choice..thats something most valuable you will have in your hands, and combined with renderer flexibility and graphical output, you must love it...high high recommendation from my side, and just small note, as other mentioned, final output entirely depend on your programming skills, so if that is polished out, everything else will be a dance..

..thats my thought roughly as well..considering LE to aim AAA class, why not do similar things with toolset AAA teams using, such as 3dsmax, Maya, Lightwave, XSI..i could suggest some nice solutions but since this is pureLIGHT thread ill not talk about it, anyway, if Josh read this, let me know are you interested so i can send you a link ..

..im really interested to know, what are real benefits of using pureLight over Vray or mentalRay in 3dsmax, if I have 3dsmax already ? As a non benefit, im not considering 10 minutes of rendering i need to get LightMap from Vray, since its rendered once anyway, and thats all..im not trying to be negative really..I just want to see, is it worth for me to spend additional 350(later 500) US$ on this system or not..I couldnt see any really advanced lighting done in pureLight on their web site, and i would like to see some (no need to be related to LE), in order to really see its capabilities in comparison with systems i have already..

..this is nice official addition for lightmapping..I am not sure about purchase of pureLIGHT since i have already 3dsmax + Vray, and it can do the same (and better) things far as i can tell..it is however very handy solution if people doesnt have any advanced offline renderer in hands..really nice..is this price temporarily 350$ for LE or it is real price (im asking because its cheaper than other versions, so im wondering, whats going on) ?

..i would like to second what darrenc182 said, in sense, that, I have no issues to see updates going on, thats great, but it is very hard to follow when you update and realize that structure you wrote before, is broken in some places and require work around same things again and again..this is not a problem for hobbyists since usual its work over very small amount of data and media, however, when you working over real game with loads of elements plugged in there, its an horrid work to catch what is wrong and suppose to be just okay since its using same commands as before and it was working just fine...thats why im 'steady' on 2.31 because im really scared to change now, due massive amount of media i have incorporated, and i have no time to go again trough all libraries i wrote to change things... I would like to see also more support for developers who are on commercial track, and maybe some sort of locked thread should be for such use..so support could be anything..from very specific shaders required, up to features needed, if any..on that way, fusion will be better as, such work will be sort of simbiosis between LE and developer and i believe its worth time for LE side because promotion and advertising trough finished games is way beyond any talk over on forums and what not..so, its worth in my book and it should be set i believe.. Money..well..i guess, primary target of LE is AAA world..having said that, anyone who has started game in such direction, most probably have money and corresponding media, or, 'discarding' will be done by publisher anyway. So how to use money if I have it?? Well..I do have plans for LE, and some sort of support of its development. Specific details i will leave to reside between me and LE author, but it will be clear to me, what to do, after i see v.3.0 out and what is it about. It is important for me since im making a living out of games, and Im interested to see LE in areas im looking for, since, after Hidden Dawn, PC is not anymore only area im looking for,and thats something what will define my future steps for sure, so thats why my decision is tied to v.3.0.

..working fine here with all vfx enabled(no wireframe) at 1920x1080 and between 17-30 fps /win7 64 bit,4 gig RAM,nVidia GTS250, 2.8 gig VRam/ ...nice work...by the way, how many polygons is this entire scene?

..real beauty ill check it soon as i get back home

..of course..geezz..phyre phyre

..simple..why this code doesnt return any pick when i select different pick types, while without pick type definition, everything works..so.. why this works: Local plane:TMesh = createcube() ScaleEntity(plane, Vec3(10, 10, .01)) EntityColor(plane, Vec3(1, 1, 0)) EntityType(plane, 1) Local cube:Tmesh = createcube() MoveEntity(cube, Vec3(0, 0, -5)) EntityColor(cube, Vec3(1, 0, 0)) EntityType(cube, 2) Global pick:TPick While Not KeyHit(KEY_ESCAPE) fw.update() fw.Render() pick = CameraPick(fw.Main.camera, Vec3(MouseX(), MouseY(), 1000)) If pick <> Null If pick.entity = plane DrawText"PLANE PICKED", 10, 10 If pick.entity = cube DrawText"CUBE PICKED", 10, 40 End If Flip(0) Wend End ..and this, entirely same code, just with selection of collision type i want to detect, doesn't ? Local plane:TMesh = createcube() ScaleEntity(plane, Vec3(10, 10, .01)) EntityColor(plane, Vec3(1, 1, 0)) EntityType(plane, 1) Local cube:Tmesh = createcube() MoveEntity(cube, Vec3(0, 0, -5)) EntityColor(cube, Vec3(1, 0, 0)) EntityType(cube, 2) Global pick:TPick While Not KeyHit(KEY_ESCAPE) fw.update() fw.Render() pick = CameraPick(fw.Main.camera, Vec3(MouseX(), MouseY(), 1000),,1)'trying to pick Plane entity, but it doesnt work with cube entity too.. If pick <> Null If pick.entity = plane DrawText"PLANE PICKED", 10, 10 If pick.entity = cube DrawText"CUBE PICKED", 10, 40 End If Flip(0) Wend End ..what the heck im missing here ?

yes..Grid generator will find entrance so search algo will not get confused..Ill prepare few extreme situation meshes to demonstrate that ..

well..every system has some advantages..but from my personal set of tests, i realized that navmesh has no real advantage over well organized grid system generated from navmesh. Amount of control you have in case of use such grid system compared to navmesh only is massive. Also, search speed can be controlled directly by heuristics and grid size. Such changes on navmesh itself require new navmesh and its a lot of work. Bottom line is, with navmesh you NEED to search your path anyway with a-star and there is no escape from that. Raw navmesh doesnt contain unwalkable / blocked path out of box, they need to be calculated as well, so once used in real world scenario, things are not that ideal as they seems to, on empty road or level with no npcs or props, etc...what i really didnt like about it that after you set navmesh manually (you have to), you are still out of searchable grid necessery for search. And when you have 40 levels and plenty of props, thats not a joke. Contrary, this simplified version of my system used in game im going to expose in lessons, does job in 1 code line. Done.

..no problems at all Rick..idea about algo is to use less engine commands as possible, and commands used should be natural part of any renderer, so it can be easy to plug anywhere..Bmax is language of choice i mentioned at begining because entire OpenCL port of system i use in my game is done in Bmax too. But once you see code, it will be really easy to convert since i have broke down every single execution step in to its own method, but i can convert to C++ and post it, no problem with that too..here is description of initial command: GRID:TGrid = TGrid.Create(gridXsize:Int, gridZsize:Int, nodeDistance:Float, startExpansionPosition:TVec3, navMeshFileName:String,verticalOffset:Float, levelFileName:String) gridXsize = number of navmesh nodes generated on X axis gridZsize = number of navmesh nodes generated on Z axis nodeDistance = distance between generated nodes at initial stage (unbiased) startExpansionPosition = point from where nodes creation expand over navmesh surface navMeshFileName = navMesh file name to be loaded verticalOffset = offset for each node, determining how accurate node grouping will be based on terrain slopes levelFileName = actual game level to be loaded for sake of adjusting availability of nodes based on real game level data and accuracy so, first 3 parameters will determine how density you want your node structure to be..and its very flexible..for more complex levels you will just increase it and have very accurate navigation..as for areas with less comples structure, just use smaller density and you are set.. in your main game loop, you will have your walkable node list just like this. before main loop (init stage): Global ShortestPath:int[] Global Path:TAstar = TAstar.Create(GRID) and in main loop you can assign array of result nodes like this: ShortestPath=Path.update(source,target); note that you can create as many as you want TAstar objects, and each of them use same grid and changing grid content in runtime, so other TAstar objects will be avared of it and avoid taken nodes..

dont worry man..im very humble creature, and i like when people critisizing on constructive way, and to me, I see nothing wrong with your posts but positive impulse and discussion leading to maybe even something I have missed, really..so no problem man..if u closer ill call for a drink

..its entirely possible to add some weighting (its not included in lesson), trough heuristics so it can do exactly what you want. Crazy zig-zags are due fact that closer node in search was marked as non available because of alignement of node(uneven terrain). Thats why vertical offset is there, i just didnt used it in order to test how 'smart' algo is and is it going to get alternate route. As for waypoints..navmesh output is also walkable node list and its nothing but list of waypoints and final list is not part of cycling, its returned as a result. As for quads, its not about quads but their convex regions connected to each other, and that means parenting is important in order to know what is connected with what. Grid generator provide that easy, without necessity to render out a thing since everything is just a pivots. Try load 100 000 quads and try same with 100 000 pivots and let me know how renderer will like it, or memory for that matter. Each quad is eventually 4 nodes anyway, soo..and A-star in lesson is MODIFIED A-star, means there is no closed or open list, there is no processing wasted on seeking and defining parents, nothing..just plain look up over grid data what in worse can be 8 nodes(diagonal movement) and even less if you know in advance parent of each child and each child as a parent node structure without seeking that. Now, organize those nodes in to larger blocks and check those blocks against heuristics and you will be able to cut off MASSIVE amount of already minimized search steps. Its really fast..on my crappy 1.8 GHz machine i cant any ms value..its below 1ms...insanely fast..

..well.whole point is, that navmesh output is a graph based on convex regions, and its fixed..in my tutorial, principle is SAME, i do generate also grid out of navmesh BUT i control how many grid elements will be spitted out and also even then, graph will be scaled down if not fitting navmesh area properly and balanced properly over entire navmesh area so you cant see concentration points like you can see in original navmesh grid because of unbalanced triangulation, so you need to fill more triangles in order to get it right, and that means more and more graph nodes. At the end navmesh need to use grid search algo and there is no escape from that. So its same. Difference is that my grid system setting for you walkable zones out of box and NON walkable based on actual level(not navmesh) whats very cool. All your a-star need to look is walkability over grid/children(heck, doesnt have to even check parenting because its already in grid generator, what usually a-star NEED to do)..thats why its very fast...if you create on the top of that global node zones,and checking that first, its possible to cut of hundreds and hundreds of nodes just in one pass..its insane speed boost..Grid generator extract for you everything in one line of code, and its all in there, ready to use..and also you can change it on runtime if some physics obstacle appear (thats happen over result path node check)..so for entire grid, all you need is this: GRID:TGrid = TGrid.Create(50, 50, 2, vec3(-50, 10, 50), "navMesh.gmf",, "level.gmf") and u are set..