Guppy

I think you misunderstood me - I mean that even if you tried solving the scenario I put forth with instancing you would have to use LOD in addition that that anyway because instancing in it self isn't enough. I did not mean that instancing requires LOD, hope that clears it up As for the shader in g3ch16 I dont see any reason why you couldn't put that in your LE3 project

If it's an antiquated idea then please do elaborate on how you would solve this scenario with out heavy use of LOD; God sim type game where you may have in the 1000s of units on screen at any one time but still have possibility to zoom in on a few (or even one) - without LOD support you would have to use low poly models even when up close. even with instancing you need different LOD models: http://http.developer.nvidia.com/GPUGems3/gpugems3_ch02.html or maybe I'm missing something here?

Good job think I'll write on up for mercurial

Was searching the forums for how to include lower level of detail models for leadworks, when to my surprise I learned that the current incarnation of the engine doesn't support it. Is this something that is planned for 3.1? I'm not talking about automatic lod or anything fancy like that, just plain old swapping hi poly models for lower poly versions based on viewing distance of the instance

I didn't realize they changed their licensing terms to include commercial use, still not all expenses are measured in money ofc If you have no intentions of using your end product outside the whindows eco system I'm sure VSE is a workable solution.

With 3.1 compiling against gcc ( properly also clang as the two are more or less interchangable ) your free to use any old text editor or one of these fine IDEs; http://orwelldevcpp.blogspot.dk/ http://www.codeblocks.org/ http://anjuta.org/ http://www.eclipse.org/downloads/moreinfo/c.php http://codelite.org/ No need to tie your self to an expensive MS product

Supprised notting shows up in search it's not too long ago this was posted; http://www.leadwerks.com/werkspace/files/file/473-glowmapshaders-leadwerks31/

Bit late I suppose, but wouldn't http://www.leadwerks.com/werkspace/files/file/471-animated-vegetation-shader/ fit your needs?

While I realize that at the moment the priority is the full 3.1 release I cannot help but wonder how are suggestions prioritized? If it's based on user feed back then how do we provide it - liking the suggestion post, adding a "+1" post, sending Josh a valentine, etc.. If not then how are they prioritized ? The current suggestions can be categorized as: Need to have Nice to have "meh" each user will properly feel different about each suggestion, but I'd hate to see a whole bunch of "meh" get implemented simply because it's fast/easy at the cost of "Need to have" stuff.

http://powayusd.sdcoe.k12.ca.us/teachers/rdohm/Course%20Info/Assignments/Resources/Animation/3D_Anim_Lessons/images/walk.jpg ( or just google images for "walk cycle" ) as you can see the head follows a familiar pattern ( stretched sin ) - simply adjust the cameras offset to the ground accordingly as long as the player is moving forward and set it to the normal/high height when they stop.

Lacking utf-8 support is kind of a big deal, this should really be documented ( or better yet fixed )

The "f:\dd\.. " is on josh's drive - not really sure why MSVC++ insists on storing those paths in exe's - so you can ignore that. as for the error it self I looks like your trying to pass an number to a lua function that is outside the expected range ( -1 .. 255 )

Since I was talking about the license change ( from lgpl to zlib ) it's entirely reasonable to think I am well aware that the project is opensource. Given this perhaps one could deduct that I was asking if the project was designed in such a way as to let you use pieces - in this case input specifically - independently of the rest of the framework.

Seems SDL have an agreeable license these days ( used to be lgpl ), but can you break away the input part of sdl from the rest of the framework?

Try checking the alpha channel of the texture

Would be good to add support for regulare controllers aswell tho the ps3/ouya/xbox ones are more widespread and being able to use those aswell would be a huge plus for the game / engine

That's not really engine specific tho

Fixed the link - though I dont see anywhere it actually lists opengl capabilities, so I guess we are to figure that out our selves based on the gfx card list

http://mercurial.selenic.com/wiki/QuickStart It may seem a little overwhelming at start but it's really worth it, the main advantage of mercurial is that it's a distributed system. So each developer has their local code under revision control aswell, and the version db is stored with the code - so if you take a copy of the code you get complete version history aswell ( making backups quite a bit easier )

Not only that but you can host it your self on a nas or other lowpower device ( think raspberry pi, beaglebone black, etv)

Just a mass larger than the player, no? ( that way you can still knock over the fence with a truck or explosion if so desired)

You have ofcourse the latest catalyst drivers installed?

It's certainly worth bringing up for when Josh reaches the 'Integration with blender' goal

http://vimeo.com/84168438 goes "VimeUhOh could not find that page", still uploading?

Check the bone rotation of the fingers