Niosop

Great work. I'm so envious of you artist types.

Naaa, the can be greater, they'll just either wrap (1.5 == .5) or clamp (1.5 == 1)

I'd rather have an in editor physics shape and joint editor

Tried to auto create some normal and spec maps for it, but didn't look that good and definitely didn't justify the increased texture memory space. I did clean up the model a little more to remove most of the most noticeable seams. If I get the urge tomorrow I may re-unwrap it and manually create normal/spec maps for it, maybe record the process in case it might help anyone. Here's the latest version. bombedstable2-new.zip

Yeah, the API provides a way to get feedback. I'll need to look at it closer to see how friendly it is, I stopped researching it when I saw the $5k pricetag, but if there was enough interest I'd be willing to spend some quality time w/ it.

Were you planning on adding a specular map and normal mapping it? If not, would you mind if I took a shot at it? It's really a nice model, I'd like to see how it looks when it's all decked out. I fixed up some small problems where the UVs were slightly off (maybe a rounding error during the conversion or something) that resulted in some seams, going to work on the lighting issue next.

Oh, the video portion is LGPL so can be used for free in any game as I posted it. The Awesomium library is the wrapper around Chromium to render web pages onto a texture, and that's what costs. One of the big advantages to being able to render web to texture is for GUI systems. Since there's already a TON of JS and Flash GUI widget kits available that look really nice, being able to reuse those for your own menu system could be a huge time saver. I'm sure I can think of hundreds of other uses for web->texture though.

Wow, that is a really nice model, I wish I could do stuff like that. Anyways, I did a little clean up. First thing was select all Vertices with 'a', then 'w' and Remove Doubles. You had a bunch of duplicated verts. I don't know if they really matter much, but it makes all your edges non-manifold which can mess with other tools. Then I repositioned it on the blender origin, and set my cursor at the bottom center of the model and hit "Center Cursor" which sets the object center to wherever the little crosshairs are. Then I exported as FBX and used ConvertMesh.exe under the Tools directory to convert it to GMF. Made a simple material for it and threw it in the editor. Your problem may have been that it was being displayed but the center was so far off that it wasn't shown on the screen where you could see it. You might want to try zooming way out and see if it's there. Attached is the converted stuff and new blend file, but there are still some oddities with the lighting on it. I think it might be a normals issue or an issue w/ non-manifold edges. I'll see if I can clean it up some more, but here's the current version. Why is it all tris already?

Hmm, I don't see a method of downloading the video and I don't have the original. I should have uploaded it to youtube instead. I'll see about redoing it (better this time hopefully) and I'm going to do another one on retopology soon. I'll use YouTube from now on so it's downloadable and seekable. You can use the center to cursor button to set the origin. Just click wherever, usually have to do it from 2 views, like a front and side, so that your cursor is where you want the origin to be. Then click center to cursor I think. I'll add that into the redone skeletal animation one.

Odd. Could you zip up the obj from blender and the texture and post here? I'll see if I can replicate/find the problem using just blender and LE. Don't have UU3D to test that step, but may be able to figure it out w/ the original.

I did a search for "uber handsome sex machine" at monster.com. A lot of machine operator jobs, but nothing that really matched my dubious talents and attributes. Guess I'll stick w/ my current job for a while longer until the market picks up, but that doesn't mean I won't continue enhancing my skills for when it does. But a little more on topic: If BMax makes you more productive then, by all means, use it. It depends on why you're making a game. If you're doing it for experience, then maybe use C++....and maybe don't use LeadWerks because it's not really an industry standard yet either. But if you're doing it because you want to make a game, then use whatever works for you.

From what I've seen, in LE scale should pretty much always be 1,1,1 because rescaling an object doesn't rescale it's physics. So, scale it appropriately before importing it.

Yup, everything needs to be a DDS.

Happens to a lot of us. Rebooting your computer seems to fix it

Are you wanting to compile for speed or to protect your scripts? There won't be much speed increase except for initial load because the scripts are compiled to bytecode as soon as they are loaded I think, so you'll get faster startup, but the same execution speed.

LOL. While I agree w/ the sentiment, I don't think the GPL or the courts would see it that way.

From http://articles.sitepoint.com/article/public-license-explained Statically linking against GPL code would be embedding, which places your code under the GPL as well. From the GPLv2: The important part is: By including GPL'd code, it is now "part of the whole", and your application is "a work based on the Program". Which means that the "whole", your game in this case, must be released under the GPL. Once your under the GPL, then you have to provide access to the source under section 3. Because you have to include "any associated interface definition files", which, I believe, would include the LE headers since LE isn't considered a "major component of the operating system", you really can't GPL your code, thus can't statically link against or include GPL code in your program because you don't have the right to distribute the LE headers. Dynamically linking is a little more complicated, but in general the consensus seems to be that if your game relies on interaction with that DLL then the DLL would be considered a part of your program. The LGPL was specifically created for this case. Libraries under the LGPL can be linked to dynamically w/o imposing any restrictions on your code. My recommendation, don't use GPL'd code w/ LeadWerks. LGPL/BSD/MIT licenses are fine, but the GPL isn't compatible w/ the LE license *as far as I can tell*. The Tivo related portion was in response to how Tivo did stuff. They released the code as required by the GPL, but they had an encryption key on the hardware so that even if you modified the source and recompiled, there was no way to upload your modified version on to the Tivo, making the source kind of useless. So they were technically in compliance with the GPL but grossly violated the spirit of it. GPLv3 added language to address this case.

Did you create a LeadWerks material file? Adding the texture in Blender pretty much just determines the name of the material file that will be loaded automatically. You still need to create the material file that tells it what textures to use and what to do with those textures. As for size, decide on a scale and go by that. I tend to use the oildrum as the base, but you could use any of your models. Then scale everything to match your reference. EDIT: Damn mack, that was quick (that's what she said).

What do you mean? How much you should scale them down? I usually go by the assumption that 1 grid block is 1 meter.

Right, so you're incorporating the GPL code via the #include statement, which places all your code under the GPL, and you're required to comply with the terms. Which I am not sure is possible w/ LE since you can't distribute LE source code. There's an exception in there for operating system binaries, so you don't have to include the source to Windows components (which you don't have), but LE wouldn't fall under that category AFAIK. Many GPL projects use a dual licensing scheme (like FFTW, ExtJS, etc), where you can use it under the GPL for free, or contact them for a price to use it under a different license. I think FFTW is the best code available for FFT calculation, and they do offer a non-GPL license, but you'd have to contact them for pricing. If you wanted to release a free game using Ogre3D, then you could use any GPL code you want because you can include a link to the Ogre3D source and your code. And you could even sell the game, but it's effectively charging for distribution since anyone who bought it would be free to give it away, or sell it (charge for distribution), etc.

If it's sourceless then how are you integrating GPL'd code? But, the main idea behind the GPL is that users of your software have the right to see how it works, make changes to it, and distribute the changes. If they can't do so w/o the LE headers, then you would need to distribute those, which you are not allowed to do. I really don't think LE is compatible w/ GPL code. I'd stay away from it and look for MIT/BSD/other open source license that allows commercial reuse of code. LGPL would also work as long as you dynamically link instead of statically link.

And yes, you are totally allowed to charge whatever you want for your program...but the person you sell it to is under no obligation to keep it secret, must be given access to the source code of the program, and is entitled to give it away to other people.

That's saying that if you never release the product then you don't have to do anything, but if you do release it then it has to be under the GPL. And that's specifically talking about modified versions of the GPL code. Here's the most relevant section that I could find from http://www.fsf.org/licensing/licenses/gpl-faq.html Basically you can do whatever you want with GPL code as long as you don't distribute your program. So if I wrote a cool game for my daughter to play, then I wouldn't have to release source code at all. But as soon as I wanted to give it to someone else, if my program incorporated GPL code, then I'd have to release my code under GPL or compatible license as well, which means giving them access to source code and ensuring they have the ability to make modifications and are allowed to freely redistribute it. Clearly this won't work for commercial software. LGPL on the other hand only requires that you release any changes you make to the LGPL library, but as long as you are dynamically linking w/ the LGPL library, you don't have to release your own source code. So, if you made a separate program that did the FFT calculations and wrote them out to a text file, and your program read from the text file to get the data and display it, then you could use FFTW and just release your little program that wrote the file under the GPL while keeping the main portion of your program proprietary. But if you actually included any FFTW code or statically linked to FFTW, then your whole program would have to be released under GPL.

That would be LGPL, which allows you to link against the libraries w/o placing your own code under GPL. The libtheoraplayer library I used falls into the category, which is why I include the DLL instead of staticly linking against it. GPL requires you to place your own code under GPL if you include any GPL code. Which I'm not sure is even possible because I *think* you would also be required to include everything required for people to be able to modify and rebuild your code which would mean distributing LE, which is against the license for LE.

If you're saying to generate a series of textures then yeah it could be used. If you mean for realtime use w/ LeadWerks, then you may not be able to use it as it is GPL, so not really suitable for commercial use.