Niosop

Yeah, I could manually paint the whole map w/ a low strength, just not nearly as convenient as just hitting fill though

Could an opacity slider be added to the editor for when you're filling an entire level with a texture?

Cool, thanks

Ahh, thanks Blitzbat, I hadn't thought of that.

Does Spawn have to return the entity? In Update do you have to use something like: local model, entity for model,entity in pairs(entitytable) do if model.world==world then ... end end

I was looking over the terrain shaders and the functions that are available for terrain currently. I don't think you have to make any changes for us to do implement our own psuedo-streaming. The only thing would probably be vegetation since the format isn't documented and there's no functions for loading like there is for terrain data. Expose some vegetation loading/setting functions and we'd be set. To add to the above list Dragon Age: Origins was area based and it has to be one of the coolest RPGs I've played. It could have been made in LWE, as far as I can see it didn't use any technology that LWE doesn't offer, just a ton of assets. Anyways, Josh, your current priorities seem to be fine to me. Single state Lua, more terrain texture layers if possible, maybe some sort of GI someday if you figure it out. I think we can do a lot right now just by swapping out terrain heightmaps, textures, and alphas in a controlled manner.

Exactly why I'm using LWE The UDK was too restrictive in some ways. It does have some awesome tools though. I'm hoping to replicate some of them for LWE. I wouldn't worry about implementing streaming/paging of either terrain or assets in LWE itself, leave that to the people who want to use it. But you have to make it possible for them to implement it themselves, which right now doesn't seem possible for terrain. I'm not sure if it's a limitation of whats exposed by the engine or just a documentation deficiency.

Yeah, seems like everything is doable ourselves as far as loading in assets as required except for terrain portions. Would need to be able to load multiple terrains and position them. Then could do the loading/unloading yourself to make arbitrarily large terrains and such. Maybe just set a cap on the max total loaded in at once for performance reasons and leave it up to the user to page in/out as needed to stay under these limits.

Unreal 3 supports streaming of assets/scenes/etc (http://udn.epicgames.com/Three/ContentStreaming.html), as does Unity3D and Unigine (supposedly, I haven't gotten around to testing it yet in Unigine). It would be a nice feature to have. LWE seems like it could do much the same thing, even over the web using the http and caching features of the abstract file system. Does LWE support async/background loading or are all the Load* calls blocking? Is there any reason we couldn't implement our own threaded background loading system by calling Load* in a separate thread before it's actually used? I guess the only thing missing in LWE that we couldn't implement ourselves would be streaming terrain. Maybe having the ability to load terrain blocks would satisfy everyone, then leave it up to them to load/unload/position them properly. Anyways, Josh says he's bumping the number of textures which will be a nice start. All in all LWE is still the best I've found when you take into account licensing terms/cost, lighting, features, performance and ease of programming.

Just set the frame no to some random frame (math.random(start_frame, end_frame) or similar should help), then in your Update instead of animating based on apptime, animate based on apptime-lastframetime.

Thanks!

Hmm, I'm really confused by the LOD system right now. I have a model w/ two LOD levels (base and LOD1). In the Spawn function I Notify(model:CountChildren()). This displays 2, both Mesh objects. During the update cycle I display model:CountChildren() in the entity's Update function. If the camera starts in range of the model to display the base LOD, then CountChildren() switches to 1. If the camera starts far enough away that LOD1 is displayed CountChildren gives 2 until you move close enough that the model switches to the base model, then will remain at 1 regardless of how far away you move. The actually LOD model switching works fine, it's just the CountChildren function that is confusing me. Anyone have any ideas of what it's doing?

How do you get the LOD that's currently in use for a model? Specifically I'd like to do it in Lua. GetModelDetail doesn't do it (it returns the LOD base level in use). I suppose I could calculate the distance and go from there but I'd rather use a built in function if there is one.

Looks like you haven't created a SetKey function. Look at the switch.lua script to see one example of it's use. Your SetKey function could be as simple as: function SetKey(model,key,value) return base_SetKey(model,key,value) but usually you'll want to add some code in there that will actually look at the key and value sent and do something to an entity variable. So something like: function SetKey(model,key,value) local entity=entitytable[model] if entity==nil then return 1 end if key=='State' then entity.state = value else return base_SetKey(model,key,value) end return 1 end You'll also need to implement GetKey

Good job. I'm always impressed by your work, especially your recast integration work. I was working on my own implementation of using animation data to drive the entity movement where everything is controlled by animation speed. This works for me because I'm using motion capture data that already has fairly well synchronized translation of the root bone translation and foot placement. The code is messy so I won't post it yet, but the basic idea is that every update: Check how much time has passed since the last update. Use this time to determine how many frames have passed. Animate to the frame that was used last update, save the x,z position of the defined bone. Animate to the frame that should be used this update, save the x,z position of the defined bone. Calculate the difference between the positions. Set the position of the model to the current model position + the difference calculated above. Set the x,z position of the root bone to the x,z position of the model. So you drive everything by setting the animation speed (last_frame + time_difference/scaling_factor) where a higher scaling_factor gives a slower playback speed. The movement speed is always in sync with the animation speed. It can be extended to properly handle blending as well by storing the different animations used and blend factor as well as the last frame. It handles lurching/non-linear movement very well, which is a bonus for some of my animations. And it ensures that the collision shape for the model is always at the same position (if not rotation) as the visual representation. Plus it's only a dozen or so Lua lines. Of course this requires that your animation has movement in it and is not locked to the same x/z location like most that you can purchase. I'd love to see a simple to use system that would allow you to choose (in the editor) between: Using animation driven movement/rotation for animations with translation data Using your method of analyzing foot travel for animations w/o translation data Manually moving object Doing this on a per animation or per state basis would be cool. Now I just have to make it account for rotation so instead of rotating your model, you could play X number of frames of a rotation animation to get it to the rotation you would like (mostly useful for smoothly turning >=90 degrees). I should also try pre-calculating and caching the x/z and rotation deltas per frame as I don't know how much overhead is involved with doing two calls to Animate each update per object. Moving it to C/C++ instead of Lua would help a little I'm sure. Anyways I'm really looking forward to what you come up w/ next (especially in the recast integration area). Think I'll start working on IK foot placement for smooth stair/hill climbing next.

Look for the ActionSnake demo someone posted here in the forums. It's a pure Lua implementation and shows how to use it w/ engine.exe.

Part of the reason might be that the people who were beta testing it were already used to doing things one way. Whereas I (and I'd assume others) only licensed LWE because per entity scripting was added in 2.3, and therefor are a lot more likely to place code in the scripts instead of the exe. Speaking of which, any update on an ETA for the single-state system release?

You can add them in the editor. Add an Atmosphere object then double click on the instance and choose the skybox material you want to use in the properties.

I think he's saying that it will now be easier to just call object:StartWalking() on the character than to go through an intermediate message sending system.

I'm evidently lacking some rudimentary knowledge. If I wanted to paint the color 200,200,200,255 (RGBA) to the top left pixel of the screen, how would I do that? Or if I wanted to paint the same color to the top left pixel of a texture, how would I do that? Without using SetColor and Plot I mean. What I'd really like to do is write out YCbCr data to a float texture and then use a pixel shader to convert it to RGB to speed things up, but for now I'd be happy just to be able to write arbitrary data to a TTexture.

Yes, playing fullscreen video like that is fine, and probably performs a lot better than populating RGB data. But it doesn't give you the ability to render to a texture that you could then map to an object like a TV in game.

Thanks for the info, it is enlightening. Just for fun you might want to throw Sun Studio 12 into the mix Not that it would be applicable to LWE at this time. I didn't realize that the core engine was actually written in BlitzMax, I thought it was just a supported language. Or is it just required as a dependency for the BlitzMax support?

Did you rotate the directional light so that it's not pointing straight down?

Right now the Lua scripting system is multi-state, which means that each Lua entity is it's own self contained island. They can't access global variables or talk to each other without jumping through a lot of hoops. Moving to a single state will allow global variables that are accessible by all the object scripts and make it so that objects can directly call functions/access variables of other scripts. It also looks like he cleaned up some of the naming conventions so that entity vs TEntity isn't confusing anymore. Upside: A lot more flexibility in your scripting, cleaner code. Downside: If you wrote a lot of Lua scripts for objects already, they'll require some modification. At least that's how I understand it, but my understanding is often lacking.

Since you're a source owner, I'm assuming you could recompile the engine using VC++ (assuming there's not TOO many things you have to change to make VC++ happy) and check actual framerate difference on a scene. If you suddenly find yourself w/ an excess of free time and no way to fill it, knowing if using VC++ would increase the engine speed could benefit the community a lot if the engine.dll runs significantly faster. Is there a lot of assembly that would be a pain to modify in there?