Niosop

Here's the tutorial. It kind of sucks, I recorded a better version right before it but my browser crashed and it was lost Anyways, as I was making it I was thinking I could make an entire series of these documenting all the required steps for making a simple game in LeadWerks. Project setup, modeling a base character, high resolution sculpting and painting, retopologizing, baking textures, creating normal maps, creating DDS textures and the pros and cons of different DDS compressions, modifying shaders, making materials, animating, Lua scripting, C++ code, level design, AI, etc, etc. Basically document the whole creation of a game with at least one example of each element. I might have two alternate version of certain parts, a free tools only version and a version using the tools I normally use (Blender vs ZBrush for sculpting/painting). I use mostly free tools anyways, so pretty much anyone could follow along w/o having to spend money on tools. Do you think there is a demand for this? It seems the average LeadWerks user is a little more savvy than the average Unity user (mainly because of the price difference I think) so they may already know most of this stuff. Also, do you think anyone would pay for them? It would be a fair amount of work to put together, so I would like to make something off of it. There's people here who are WAY better at each individual portion of creating a game than I am, but I'm in a pretty good position as far as having at least a halfway decent grasp of every step of the process from content creation through code. If you think people would pay for it, what would be an acceptable price point for say 20 or so hours of video? Anyways, just an idea, here's the link, LOL. http://www.screentoaster.com/watch/stVENWQURIR19bQFlfX1xYUVRS

Bye.

I agree about the 2.5 alpha's, I like the old interface. But supposedly pretty much EVERYTHING can be mapped to a key so I'm sure they'll have an "old-school" keyboard layout available. But yeah, it's so much quicker, to hit g,x,3,enter and move something 3 units along the X axis. s,y,-1,enter to mirror something along the Y axis, etc. Whenever I try and use another modeling program now I get frustrated because you have to click on so many buttons and look through so many menus to do what you want.

Destroying the parent will remove the child. Try object.basement instead of self.basement and object.model instead of self.model

K, I'll make a quick and dirty obj->add bones->set weights->animate->export->import tutorial. I'll do a better one later, but it should be enough to give you a general idea.

Were you talking about AO maps for individual models or for the scene as a whole? If you were talking about the whole scene, could you point me somewhere to learn more about how it would work w/ LE? I was thinking it would be possible for us to create a pre-processing system that would bake selected lighting into the scene to improve performance. Here's how I think it would work, but I really don't know enough to even know if this is possible with LE, or if it would be desirable if possible w/ LE. It's how LightMass and the Unity LightMapping addon appear to work: We'd need to be able to specify which objects are static and are dynamic. We'd need to be able to specify if a light is static or dynamic. We'd need to be able to specify if a light should light/cast shadows from dynamic objects, static objects or both. The engine would have to make use of that information. Then we could export all static objects being lit by a static light that affects static objects to blender or another raytracer and generate lightmaps/shadow maps/occlusion maps/whatever LE could use. Static lights that cast light on only static objects could be removed at runtime since the lighting info is baked in. Dynamic lights wouldn't be used for the baking because their properties/positions might change, so they'd still be processed at runtime. Static lights that affect both static and dynamic objects would have to be made to not affect the static objects at runtime since the contribution to the lighting of those objects would already be baked in. I think I could handle the exporting and blender integration part, but I don't know about the LE part. Anyways, let me know if this is a stupid idea, or if you're plans for SSRT or GI or whatever would make this pointless, or if I'm way off the mark and don't understand how this stuff works (very likely).

I'm sure there are but I wouldn't know what they are. Usually I just googled or youtubed for a specific topic I was working on and followed along with those. Actually that's a good idea for another tutorial, a basic Blender->LeadWerks workflow. What things would people like to see? This is my typical workflow: Base mesh in blender, export as obj Import into ZBrush, subdivide, sculpt and polypaint. Export high poly version and the diffuse texture. Bring high poly version back into blender and retopologize, unwrap and animate. Save as .blend file and export to FBX and OBJ. Use xNormal to create normalmap, transfer diffuse and optionally create AO map from the high poly and low poly ones. Convert FBX to GMF and bring into LWE. I won't make a ZBrush tutorial as there's tons of them out there by people who are WAY better with it than me. But any of the blender or xNormal stuff I'd be glad to record tutorials for. What do you guys need? I figure it's best to give tutorials on free stuff because then everyone can use them, where as not everyone could use a 3ds Max->LWE tutorial since it costs so damn much.

Well, if free is in your price range, I really enjoy working w/ Blender (even through I have access to Maya and 3dsMax). It's bone heat skinning system is really nice, you can set up IK animations w/ constraints and it will export to Collada and FBX. Its controls take a little getting used to, but once you do get used to them you'll find you can be VERY productive (single key shortcuts for most things, one hand always on keyboard, other on mouse). It will import BVH files if you want to use MoCap data. It has a nice IPO curve editor. Its major drawback is it won't import FBX, so it's pretty much impossible to get animated models back into Blender, but it will import static meshes and export animated ones just fine. And since it is also a modeler, if you notice some little thing you want to tweak while you're skinning your model you can do it w/o having to jump back to Modo, make the change, then re-export/import.

Yeah, I agree that the pdf is a little hard to grasp on it's own. I'll look at doing a video tutorial like the others that will help people get started if I can find time. I just noticed how much time I was spending adding features to LE instead of actually working on game code or doing paying work. Not that I'm complaining, I've been having fun, I just have to catch up on some projects to pay the bills, then I'll jump back into LE stuff.

The basics are explained in the "Getting Started With Lua" PDF, but it is pretty confusing. Everything I've learned has been just via looking at how the existing scripts work and google searchs when I want to understand something specific that I find in them. Of course, you don't HAVE to use Lua if you don't want to. You can still iterate through the objects in your C++ code and use the C or C++ API to do everything Lua can do. The main advantage to using Lua is that the Lua scripts will execute while in editor while your C code won't.

It stores the terrain painting info. The base texture isn't stored as it covers the whole terrain. The red channel stores where the second terrain texture should be painted and it's opacity. blue=third, green=forth, alpha=fifth. Or something like that, I haven't verified the order but that's basically how it works.

Not sure, I pretty much use blender exclusively. In blender, when adding a new primitive you just have to make sure that you are in object mode and that there are no other objects selected. If you modeled it all as one object and would like to split it up then you can select all the verts and choose Separate to make those verts into a separate object. I'm sure the other programs have a way to do it. If not I guess you could use blender to do so, you'll just need to export as OBJ from the other program, import into blender, split it up and re-export as OBJ or FBX. I really wish there was an FBX importer for Blender that handled animations, it would make my life so much easier. Anyone out there familiar w/ Blender and wants to take up the challenge? I know there are a TON of people out there who would love this, you could probably set up a fundable.com group, set the target at $2K or higher and quickly get that much if you get a working, robust importer working.

You need to have separate objects in the same file, not just separate groups. Each object in the file will be a separate mesh.

For my videos that require more than just the 3D window I use screentoaster.com. But you can see how those turned out, not the best quality but not horrible. For just the 3D window FRAPS is the best I've found. I can usually maintain 30FPS with FRAPS depending on the scene, but again, it only gets what's rendered in 3D so isn't good for tutorials usually.

I think he means move an object to where the camera is pointing, not move the camera to where an object is.

I wouldn't think it would be physics causing it to crash. More likely once a shader that isn't supported is used it crashes.

Ahh, and we would need a way to push things into the editor. As it is, any objects created in code are displayed in editor but aren't actually modifiable or added to the sbx. This way we could have a cave stacking plugin that would allow you to select an object and it would stack the objects to make a cave, then you could tweak the cave manually after that.

Ahh, yes I see what you mean. That would be quite handy. Also, it might be cool if dragging an instance from the treeview instead of the parent object would cause a clone to be placed in the new location. This might be something that could be handled by the plugin architecture I added to the feature request forum if plugins could get get callbacks on key/mouse presses/releases/hits and a callback for object selection. I guess it would require a callback for pretty much everything so it could handle all the situations that come up, but it would probably be worth it because we could whip up and distribute features like these very quickly without having to bother Josh about it. +1

People have noticed the problem before. And I agree it's very annoying and a huge detriment to usability. They should be constant size regardless of distance and render on top of the object. As for the cloning, doesn't ctrl-drag do that? Or are you asking for something else?

Excellent, so GC takes care of actually destroying them once they're no longer referenced anywhere? Same for textures I'm assuming? I just don't want to leave a bunch of buffers and textures lying around when a video clip is released.

Any idea about if you are considering adding this?

Hell, I wouldn't mind a pre-processing system. One of the awesome things about the UDK and Lightmass is the great results you get from the static lighting preprocessing. I love the dynamic lights in LeadWerks, but even with a deferred rendering system they still have an impact where as with baked in lighting the extra prettiness is basically free (not counting the pre-processing time which can be significant). A good balance of realtime and baked in lighting could really help both performance and visual quality.

And in the couple cases where it might make an impact you can always convert it over to C++ later once you're sure the functionality won't change.

The Lua isn't listed in the wiki, but a lot of the Lua stuff isn't, I can usually try a couple different ways and find it, but in this case it's either not there or I just couldn't figure it out.

Probably not. All they do is call engine code so the only real overhead is the function calling overhead and the binding code. Since it's only run once per frame or physics update and it's not doing any of the heavy lifting itself, then it's probably negligible.