Niosop

Have you tried restarting your computer to see if the problem goes away? I notice a lot of weird timing issues start happening w/ LE after a while, a reboot seems to fix them. Not sure if it's related though.

Lol, true.

Yeah, they're built async, but they're built after LoadScene returns I think, so at that point a progress bar isn't needed.

Not really, LoadScene will block until it's done. Pretty much the only way around it is to save out two versions of your .sbx. One that includes only the terrain and terrain and vegetation, the other that includes all the models. Use LoadScene to load the terrain one since we don't have access to the commands to create the vegetation layers in code. This should load pretty fast. Then manually parse the model sbx and place everything in code, updating the progress bar in between.

Don't the 2D commands draw directly to the BackBuffer? I'm not sure if they even look at the world that's active.

Very nice. I'm doing something VERY similar right now, but using Unity3D at the moment as I'm a lot more productive with it's tools. Once I have gameplay nailed down and debugged I'll work on porting it over to LE for the improved visual quality....not looking forward to that too much, going to be a huge pain setting up ragdolls and other physics stuff w/o a visual editor, but I may be able to just take dimensions and coordinates from Unity and plug them into LE. At least that's what I'm hoping.

You could use a shader, check out this presentation on how they did a progress bar and then expanded the same thing to do bigger effects. http://unity3d.com/support/resources/unite-presentations/shader-tricks-in-game-production

Draw it when you're in sniper mode, don't draw it when you aren't...

Yeah. I ran into the same problem, I need to adjust position of the characters exactly each frame but still have them both affect other objects and be affected by other objects. I wasn't able to get a good balance in LE, so I just switched over to using Unity for a bit. Once I get everything worked out there and have a prototype I'll come back and work on porting it to LE.

Reset its rotation every frame?

Yup, then you'd apply a Vec3 like (0, 1, 1) which would be a 45 degree angle if you are using it's local coord system...or it might be -1 for the Z component...Scale the Y and Z to adjust force, so it might be (0, 50, 50) or something. AddBodyForce applies the force to the whole body, so you don't need to worry about applying it to his midsection.

Use DXT5 if you need an alpha channel (for spec, opacity, etc). Use DXT1 for diffuse only textures.

He's just saying that by the time the DrawImage command is called the Scene has already been loaded. So while the scene is being loaded, nothing is being sent to the video card, so whatever happened to be in video memory is going to be displayed.

I think TerrainHeight just returns the value of the heightmap normalized to [0,1] at the x,y location.

Are you using the new SSDO shader in the Editor and not in bmax?

Hmm, the ctrl + right/left click functions don't seem to be working for me. Any stupid mistakes I might be making?

Thanks for keeping us updated. It's nice to know what to expect.

Just beat Shadowgrounds. Not bad for an indy team. From the credits it looks like 4 programmers, 7 artists and 1 sound/music guy. Update: Just fired up Survivor. Looks a LOT better, I'm impressed. Same basic game play, but camera control has been tweaked a little, a little more depth added (a little more RPG like feel), they moved to PhysX, lighting has been vastly improved, now there's spec on the textures. It looks a lot like what I'm going for.

Steam has a pack with Shadowgrounds and Shadowgrounds Survivor for $4.99. It's not the best game ever, but worth $5. I mainly noticed it because I'm working on something very similar right now so I figured I'd check it out and maybe get some ideas. It seems to use a mostly dynamic lighting with some baked in lighting on the few non-destructible things around. Everything looks a little flat though. I think it might be due to lack of specular textures? Hard to say. Anyways, just thought I'd mention it.

See, it's stuff like this that makes me glad to be using LE B) Frequent updates that address things that we ask for. Thanks Josh!

If we could assign an existing bone weight matrix to a duplicated mesh then we could create our own non-instanced copies of a model. But the API doesn't give us any access to it.

Yeah, I get the same effect. I think it's the background showing through, so it appears white in that scene. I think it's that the different raycasts miss that little area so it doesn't draw any occlusion information right along the edge so the unshaded background shows through.

I don't think he needs a unique selling point. Right now the visual quality of the engine IS his unique selling point. What he needs to do is stop looking for unique features and add in stuff that the other engines have that improve workflow and the asset pipeline. Things to take from Unity: * Visual in-editor physics and joint editing w/ constraint visualization. Or better yet, something like the UDK's PHAT editor. Having realtime physics in the editor is great but creating the physics assets is still a big pain. * Clone their asset importing pipeline. You can't beat dragging an asset into the editor and having it be automatically converted and just double clicking the asset to automatically launch the associated editor for that asset, make changes, hit save and have it be re-imported into the engine. It's a MAJOR time saver. * Prefab support - another HUGE thing we're missing. * Multiple scripts per object - it's nice to encapsulate code into small snippets, then just add the snippets that are desired to an object. Much easier than opening the lua file for that object and adding in includes and function calls to include the code you want. And cleaner than making a thingoid that you have to drag into your scene and link to your objects. * More than 5 terrain textures. Things to take from the UDK: * A static lighting baking option like T3D's PureLight or the UDK's Lightmass. Yes it's expensive in terms of additional texture memory required. But it can make a big difference when used judiciously and the fact that it's easily misused isn't a reason for not offering it at all. * Node based material editor. The shader system in LE is already based on snippets that are conditionally included. This could be taken to the next level so that each material can have it's own unique shader that is built at startup AND REBUILT WHEN IT CHANGES. It's a big time killer to close the editor, edit the shader, start the editor, check the results, repeat. Josh has already said he'd like to implement this. Many of these aren't engine issues at all and could be implemented w/ the current LE API. But they would require that we totally rewrite the editor from scratch to add them. Making a plugin system for the editor that would allow you to add your own menu items, popup windows, receive all events from the main editor process to act upon, send commands back to the editor, etc would allow us to write some of these ourselves and take some of the load off Josh. Anyways, I think I've mentioned all of these before, but I think it's pretty important that these are addressed to stay competitive. Just my $0.02.

The one on the left is being lit by primarily by ambient light, the one on the right is being lit by ambient light and the yellowish light being reflected off the sand.

GI and AO are NOT the same thing. AO only takes ambient light into account, GI takes all lights, the way they bounce and their color into account. And no matter how many times you say it, LE is not in the same league as CE3. It might be close as far as rendering, but it's the tool set that makes a development environment and LE isn't there yet. But it's within my price range which makes all the difference.