Rastar

With the new vehicle physics, ocean water and upcoming vegetation painting - why not an outdoor racing game? Would give Josh some feedback on the new features, and maybe he'll come up with the road tool sooner . Maybe we could also give multiplayer a shot. And of course, I love outdoor stuff...

All I can say is that I seem to have similar problems http://www.leadwerks.com/werkspace/topic/11618-problems-with-lua-c-binding/ If I compile my luaToC++ gluecode into the project, as soon as I assign any Lua script to an entity (or a Lua-based postprocessing effect), the game will crash right at startup.

Does the main framebuffer have a stencil buffer? Is stenciling enabled? If so, are any particular mask values already being used by the renderer?

Yes, he said it would be soldiers. The idea is to have some packs that can be used together, so someone fighting all those zombies is needed. Josh was confident that there will be a lot more content in the future, and also that he might approach some artists from other places like the Unity Asset Store and convince them there is money to be made with Leadwerks as well...

I am trying to bind a custom C++ class to Lua - for the first time, so I'm probably doing something wrong... I have a simple test class #pragma once class ABC { public: ABC(); }; and its binding file (luacommands.pkg) $#include "ABC.h" class ABC { ABC(); }; I run the processor from here http://www.leadwerks.com/werkspace/files/file/216-tolua/ with the command tolua++.exe" -o gluecode.cpp luacommands.pkg then include the gluecode.cpp in my build (which compiles). But if I now start the game, I get an access violation right away (even though the class isn't used anywhere). First-chance exception at 0x5150C332 (lua51.dll) in TestGame.debug.exe: 0xC0000005: Access violation reading location 0x0000001C. What am I doing wrong? Or is this not working in the beta build? EDIT: This only happens if I add the Bloom shader (which is also Lua-based) to the camera. So I guess its Lua binding somehow interferes with mine. However, I want to use my class binding in a postprocessing step, so I need a way around this issue. EDIT2: Nope, this happens if I add any Lua script to an entity in the scene.

Would be nice to have little helper members for an entity's forward (movement / camera view direction), up and right vectors. My poor little brain would have to think less, and it also makes the game code a little more readable.

Yeees, me toooooo

Thanks Rick, that's a good idea. Especially since I can make good use of the World::ForEachEntityInAABBDo variant for my use case.

Hi Roland, thanks for answering! Yes, that should work for entities loaded with the map, but I would also like to hook into events for dynamically created entities. And since I am writing some sort of generic, reusable C++ library that doesn't know about entity creation by other parts of the code, I cannot simply hard-code a hook registration after e.g. a call to Model::Create(). So I was looking for a possibility to generically hook into events for any entity, not just map-based ones. I would like to write some information about every entity in the scene after it has been rendered (using DrawHook) into GPU buffers, for later usage in the post-processing. Is there such a registration call? I am thinking of something like World::EntityInstantiatedHook (which obviously doesn't exist).

Yes, same for me. Btw, is the model also completely black for you? I have tried to recalculate the normals, but that didn't help.

Sure. The original comes as an obj, so I converted that to FBX 2015 using UU3D. sponza.zip

Not sure if this is a bug/inconvenience, or if something is wrong with my machine... I am trying to work with the Sponza scene as provided by CryTek (http://www.crytek.com/cryengine/cryengine3/downloads). The mesh isn't exactly small (some 280k tris, with 26 materials), but not monstrous either. That mesh takes really long to load in the model editor - about 5 minutes, during which one core is busy (AMB 8-core, 16GB RAM, GTX750Ti, Win8.1). Is that normal? UU3D only needs about 5 secs to open it.

I would like to have a hook function getting called for every entity in the scene, without explicitly registering it for every entity. There is a hook in the Map::Load function, but my guess is that would not work for dynamically created entities (?) Is there a method for that?

That's interesting, though I don't fully understand why that would be. By "spherical harmonics shading" you mean classical IBL like Marmoset Skyshop, or some different usage? To my understanding these two techniques would be complementary rather than substitutes, because IBL deals with shading/shadows by indirect lighting, whereas PBR tries to better mimic a material's real reaction to incoming light, no matter if direct or indirect. Certainly you can get equivalent results from traditional and PBR approaches for a specific lighting situation. What I like about the PBR stuff is that I as a non-artist can produce assets that work pretty well in any lighting situation without really knowing what I'm doing ;-) I didn't ask because I really need this like right now (I'm actually doing more prototypical work in Leadwerks because it's so accessible, but currentx develop my game with another engine). I just think that this is becoming mainstream and it will become more difficult to buy and/or create assets for use in a non-PBR engine. And sooner or later the day will come when some user buys PBR assets, imports them into Leadwerks and complains that its rendering isn't up to snuff because the asset looks better somewhere else. As for the implementation in Leadwerks: First this would need some technical additions, like conversion of textures to linear space and back to gamma (using the GPUs hardware samplers, this could be a checkbox in the texture editor) and the possibility to use higher precision frame buffers for the shading calculations. I think both are very cheap to add and also help in other situations (like rendering of skies, or doing home-grown IBL). The PBR shaders could maybe be provided by the community, e.g. by porting some stuff over from Lux, or from scratch. But that probably wouldn't work out of the box since the lighting calculations are done behind the scenes, and all we can do in the shaders is write to the G-buffers. But maybe even that change wouldn't take too much effort. But all in all I think there is a lot of bang for the buck in this. Anyways, I agree that some other, more gameplay-related features are more pressing for most.

@Olby: That is a very important argument. However, we one-man shows are probably more dependant on easy access to assets than studios. With a tool like Quixel's Ddo, even I (and I'm by no means an artist) can produce great looking assets that just work in the engine. And I would bet that with big engines all on PBR now, sites like Arteria3D and Dexsoft will go that way as well.

Just to be clear, I am not wondering if Substances will be integrated into Leadwerks, "just" the PBR shading stuff.

@Scrotie: Sure, that doesn't depend on the graphics API (e.g. UE4 uses OpenGL for its OSX renderer).

@YouGroove: I'm afraid it isn't as simple as that. While you use diffuse, normal maps etc. as well for PBR shading, they are prepared differently. E.g., the diffuse map must not contain any lighting information (like baked AO etc.) but just the physical diffuse color. Compared to a traditional diffuse map, the PBR variant usually looks very bright and flat. Metals are implemented differently, but in the specular PBR workflow the diffuse color of a metal is black (0,0,0), and all color information is calculated from the (RGB) specular color (while non-metals typically have a grey specularity with a value of about 5% across the board). The glossiness/roughness values are characteristic for a material, so you use physically measured values for those (which also means you get realistic results if you stick to that). Then there is energy conservation, which makes sure the material doesn't reflect more light than hits it. And as I wrote, you have to completely work in linear space to get good results, which e.g. requires that you convert the textures (which are usually encoded in gamma space) to linear space before shading (and then back to gamma for displaying it on a monitor). And preferably using HDR textures (which are tone-mapped back to 8bit) to work with higher precison/greater color range.

Are we talking about the same thing here? I don't mean Image-based lighting, with precomputed Spherical Harmonics parameters from an (HDR) background texture calculated using light probes. That is used for indirect lighting (and, by the way, is the method of choice for global illumination in the current CryEngine). I mean changing the shading calculations to include energy conservation, microsurface structure (similar to Cook-Torrance) and real-world material properties (instead of ad-hoc specularity parameters). This simply gives more consistent shading under different lighting conditions. Have a look here http://www.marmoset.co/toolbag/learn/pbr-theory https://www.marmoset.co/toolbag/learn/pbr-practice

I was wondering, are there any plans for moving to physically-based rendering in the short/medium term? There are so many DCC tools moving to PBR, it's getting more difficult to get along without it... Substance Painter+Designer, Quixel DDo+its Megascan library, of course Marmoset Toolbag, 3DCoat will have PBR materials soon... and I think it's looking great as well and is making an artist's life easier. Of course, textures+shaders in linear color space and HDR would be prerequisites, but they were on the menu anyways, weren't they But joking aside, really wondering if/when this will be coming to Leadwerks.

To a degree, I do experience this, yes. Not getting sick, but rather a little dizzy and "headachy". I normally don't get seasick and can easily read in a car. Apparently, you need a few days or even weeks to train your brain for this new experience, but I haven't gotten that far. A normal HUD wouldn't help, I guess. And it flies a little in the face of the immersive experience, since it doesn't move when turning your head. The normal recommendation is to have a 3D user interface in front of the player. These things are probably one of the trickiest issues in VR: You have to come up with different interaction schemes tailored to the new experience.

Nice one, working great on my end (using a GTX750)! No noticeable judder. Looking forward to the "official" integration!

Leadwerks is cool because it - has a simple, clean API that allows you to do pretty low-level stuff in an easy way (e.g. procedural mesh generation) - provides full access to all shader stages, making it the perfect tool to try out rendering algorithms - has a very friendly and helpful community - is affordable and royalty-free.

It's more for doing the dynamic tessellation of grids in terrain and ocean rendering. It would render the vertices + specified attributes into a buffer that is stored on the GPU side. That way the mesh generation performed by the tessellation and/or geometry shaders wouldn't have to be redone from scratch every frame, but rather could be modified in subsequent frames to account for camera movements etc. As an example, in this paper they are using transform feedbacks for exactly this purpose: http://www.hindawi.com/journals/tswj/2014/979418/

Is it currently possible to use transform feedbacks with LE 3.2? If not, is there a chance this might be added? Maybe even in 3.3 ? TFs would make the geometry and tessellation shaders even more valuable, and there are a number of very interesting algorithms especially for (guess what) terrain and ocean rendering that are making heavy use of them. EDIT: Oh, and I would be happy with a pure experimental, fully undocumented and completely unsupported implementation