3Dski7059

Great summary, YouGroove! I actually sat down and went through SD's "Getting Started" series and saw this. I can see where you might be able to come up with a similar node based workflow inside Blender, but SD may be more user friendly. For instance, I know that you had to tweak a lot of settings in Blender to create a normal texture, but they may have streamline this and similar texture creation features. Both routes will be a learning curve for me. As a side note, I played with Houdini a bit, but I don't have a version that will export to usable formates. It, too, is procedural based, where parameters can be set to affect characteristics as needed. You could build a chair, then parameterize lts height, or whatever. I never really stuck with if for the fact that I only had one usable exporter, but it didn't work as expected and was hard than hell to build anything in it for a game environment that would export as desired..

I got a copy of SD in hast and now trying to figure out how it can best be used to export textures that can be used by other engines like Leadwerks. It sounds like you'd have to work in such a way to limit outputs to diffuse,specular and normal to be used in such applications (apps that don't support the SD plugin). If you were to export from the final node, it sounds like every thing is simply baked into the a final, flat bitmap, so limiting its usefulness. In contrast, if export of these mapped textures (diffuse, specular and normal) can be exported to a single atlas, then that would be of benefit. So, I guess I'm trying to figure out what "export to a bitmap" really means from the SD perspective. Perhaps user "knocks" from an earlier post can give more word on that, since he's a long time user of SD. From the proprietary SD file perspective, it sounds like the engine just to know how to give control over to an SD "plugin", and I'm not sure what that means to us as developers, especially those who own the Indie version of Leadwerks.

In case xeranas, or anyone else who was wonder has this same question.... This exported creates a Leadwerks MDL, as opposed to exporting to FBX and Leadwerks having to convert that.

I have the Leadwerks Indie from Steam working, as well as an install of 3.2 Windows. I'm trying to get more involved with Leadwerks and noticed that the projects of both are in the same location. Is this OK, or will i cause a problem? I guess personally, siince the Indie version is strictly Lua based, part of me would like to keep these projects separate from the regular Windows version of Leadwers. But, it looks like I'd have to export them to a new location as necessary, then import them back into the manager.... sound like best way to accomplish a separation between Indie and Windows versions?

I figured it would something like that and sounds like it would be just playing around to get the force and direction correct. Then, I'd just have to figure out if can/should just animate the texture in the FBX.

I'm here because I was searching for information on moving a texture. Actually, my intent was the idea of creating a conveyor belt. But, then I wondered how to implement the motion. I suppose you could set up physics in such a way as to cause the player to slide across the surface at the same speed as the texture... Do any of you have experience with this implementation idea? UPDATE: As an alternative, I could create the belt as a animated model. But, then I have to figure out how to implement the interaction between things and the belt motion???

I had Leadwerks 2 Windows version on my system. Then, I purchased the Leadwerks 3 Game Engine on Steam and never tried the my Windows version after I tried to upgrade it. I think part of the issue was both installs look at the same "projects" directory, so things just got really out of sync for the initial load. I'm currently work only with the Steam Leadwerks 3 engine (Lua) so haven't tried the full iteration with VS C++, but I at least got the editor craziness resolved with a fresh install of the Windows version. No this doesn't help, but just confirmation that some weird things can happen if you've dabbled with both versions. ADDED: I went and look and noticed that my Windows version update is only showing version 3.0, while my Steam Leadwerks Game Engine version is up to 3.3. The project folder layout is different in the Windows version and it doesn't contain the FPSplayer.lua script that the 3.3 (Lua only) version has. So, now I'm wonder why my Windows version hasn't also progressed to 3.3 and what the real consequences of the differences are?!

I'll have to look around more to see what those options are and see what features they provide. Especially since I thought/think Agrror's solution was only C++ based.

I thought I read that Agrror's solution was for C++ only, I didn't include associated Lua. Regardless, I do think if there was a bit more documentation on how the Leadwerks Game Engine architecture pieces fit together with Lua scripting, creating a custom GUI wouldn't be so bad. I'm familiar with Lua and general GUI logic, so I was able to invest some time and finally came up with some highlevel toolbar GUI handling logic in a script that can be attached to a Pivot object. It took me a few hours of hunting through the docs and an evening of coding (including some clean-up) to have a solid foundation to build some real come on. The only additional thing I'd like to do is set up callbacks so that their output can be attached to some kind of battle manager script that can send hit damage against the applicable enemies, based on toolbar options (spells, etc.) So, I'll have to study the aspect of identifying in and out points for the flow GUI. As a side note, if folks are stuck on GUI development, I imagine their just as baffled about saving and loading level data, which would be another major stumbling block for me, being new to Leadwerks.

I have to admit that I'm not a hardcore Leadwerks developer, but I am an experienced developer, and now that I'm investigating it again I have to admit I've been a bit frustrated with information fragmentation, and this might not seem so apparent to those who are familiar with the layout of Leadwerks. Also, there's been a couple posts where there is a disconnect with solutions, as they relate to Lua and C/C++. In regard to a scripting solution, I've seen a great Youtube series on HUD development, which I think is a great basis for drawing. Next, I think it should be made more evident in documentation for scripting that Script.blah_blah is just the tip of the ice burg and that the real scripting API is based off of the objects in the Command Reference section of the Leadwerks site. From there, we're left to do some educated attempts at implementing the syntax at the proper location, with the correct syntax. Also, from scripting edition of Leadwerks, the only way get a feel for the architecture is to create a blank project and examine the project's directory structure. There are many styles which can affect implementation, so basic GUI provisions don't solve the problem of a new user trying to understand the best place to draw, and understand what the even handling needs to affect. On a related topic, some one questioned the possibility of there being a book written, and i got the impression that the idea was blown off. I realize I'm now getting a bit off topic, but the tutorials on the site are great for some real basic things, but they are not good for helping to promote Leadwerks to the new Indie developers that purchase it through Steam. I just don't think the information that exists will logically walk them through the architecture and help them investigate and evaluate GUI implementation techniques inside Leadwerks. Yes, we learn how to place a player into a game and its fantastic that it's interaction with the environment almost effortless. But, eventually the user is most likely going to need to learn the architecture so they can best script GUI/HUD logic, or customize current or additional functionality. The idea of creating a GUI manager, with hover and click events, is a time-tested logical approach, but there is no information that even hints toward some good approaches for scripting solutions in Leadwerks. A new developer will be discouraged, being frustrated with all the pieces of information that don't help them solve their problem, and simply quit trying, as powerful and helpful as Leadwerks is. UPDATE: In support of Leadwerks 3.3 documentation, there is a "Lua" tab option when viewing the Command Reference documentation. But, when trying to create a new blank object script, my latest copy from Steam didn't give me the option to create a object script skeleton to fill in, so I used the documentation to create my own skeleton object script. UPDATE: Script Creation Issue. Well, it turns out that the right click has to be in the bottom window, below the Assets hierarchy. I thought the right click was on the item you wanted to attach the script to ... oh brother!

I think when most people think of a mesh/shape, they think of a all inclusive wrapper for a visible objects, but is there a of rule that says it has to be contiguous? I've not tried this yet, but couldn't you simply have a mesh that's actually composed of adjacent blocks that only cover walls the player would come in contact with, leaving spaces in between to account for passable doorways or windows? Is this idea a realistic approach, or have I got it wrong?

Yes!... Maybe not so much as "projects", but I like to test out ideas in isolation. So, I might have a main project, but I'd have to set up smaller projects to test out ideas. This is especially true for even the simplest of things where I need to test my understanding... docs are sketchy and perhaps imply a certain behavior, so feel a need to do a reality check.

Thanks... Don't think I've run across that site before. I'm a programmer, trying to learn how to do some modelling. But, even if you do learn to model, texturing is the next challenge. Much happier with Blender now that they've change from their older UI and rearranged things.

YouGroove, need to get a bit more proficient with modelling, texturing and use of shaders.... really like your shot of "System Shock" remake.

You need to go to the Scene tab, select the object from the scene tree, then select the Physics tab... the 2nd item in the properties settings list is where you identify the shape file. Physics settings are probably very similar for the objects you're used in LE 2, but I'm not an LE 2 user : ) Hope that gets you going. Also, there is a LE 3, Inrtoduction to Lua tutorial at the site that touches on the topic of collision detection near the end of the video.

klepto2 points the direction to the solution. In our specific case, translation of the content at the link he shares ends up being, changing the Debug configuration's, C/C++/Output Files -> Program Database File Name from, ${int}vc${PlatformToolsetVersion}.pdb, to, ${TargetDir}vc${PlatformToolsetVersion}.pdb, Mind you, I don't know if this is the "best" solution, but it is a correction. And, it compiles much faster, since it doesn't have to contend with responding with all those warnings. I personally don't like ignoring warnings if I don't have to, since they may mean something more significant, in some future situation that I need to contend with... maybe some unexplained, unsolvable bug.

I can only say that I'm very interested in these kinds of issues as well. Understanding what will and will not work would save a lot of time, if there are some known circumstances that end with bad results. I was getting ready to test the waters with some simple animations... partly because I need more experience with creating some assets. Sorry I've no insighs to share : (

I'm a hobbyist, but an experienced coder. I would admittedly struggle with coding complex motions/physics if I didn't leave that up to some LIBs, but I think 3D assets and textures are the biggest stumbling block for me, because I'm not in the position buy them. I don't like auto-completion for the sake of having it, or for simple fundamental language syntax issues. To me, its almost indispensable when you have a new library and haven't mastered the details of the available classes-methods or functions. Sure, you can look up this info, but its much faster when you can get hints directly in the editor you're coding in. I find that syntax highlighting makes code easier to read.

FYI... I'm just running the Windows version of Leadwerks. I just forced an update, created a new C++ project and debug and release ran fine for me on VS C++ Express v10. Just thought I'd see if I could recreate the issue.

So, if you split the larger CSG into smaller parts, would the navmesh show up and frame rate normalize?

As simple as the configuration of dynamic shadows sounds, I haven't gotten them to work properly in the latest update (day before last, so had to be 5/22). In one instance, I set dynamic on a rotating CSG cylinder, which only displayed as a re-sizing square, not at all a representation of how it should really look. This was a project I had imported from the trial version.. Next, in a new project, I just placed a stationary CSG cylinder some distance above a CSG box for the ground and set the dynamic flag for that cylinder. In this case, I got no dynamic shadow at all. The shader folder and its contents were present, but I must be missing something somewhere if this feature should truly be working in a very simple scene. Also, I do see the dynamic shadow in Darkness Awaits, so I even tried copying those shaders over to my project. This didn't work on my simple cylinder-with-ground test. What might all the factors be, besides simply checking the dynamic shadows for the object? I have to admit that I don't know how to associate the different shader with any particular items, so any direction or info would be good... Thank!

Thanks, because I just ran into the same thing after updating after my purchase. Got the error, then decided to try a clean update. I would have gone nuts trying to figure what was going on (or not going on)

YouGroove, hope you got it straight : ) You really don't have to create anything, rather open up the solution file for VC++ in your Leadwerks project directory.

Aggor, a big thanks from me, also! I'm getting a lot out of them, since I'm new to Leadwerks and testing the waters before I make a buying decision. You're a big contributor!

I've seen what you're talking about in modelers like Blender, where you can explicitly choose to copy as a reference. Then, as you say, if you change any property of the original object, they all change. Otherwise, a standard copy is just that and changes to the source object would not affect the copy. Its a useful feature in cases you're speaking... You have a room full of pillars and you decide you might want a little different texture... or, better yet, you find you need to adjust the texture placement.... fix the source and the reference copies would be corrected along with it. Beats having to tweak all of them!