Josh

How is this supposed to compile?: ::_set_se_translator(straight_to_debugger);

If I throw an exception in the try block, it gets caught. If the Lua script calls a C++ function that throws an exception, no exception is caught by the catch statement.

Has anyone here done exception handling with LuaBind? With BlitzMax I was able to use Try/Catch to display the script line a program crashes on, but I can't get this working in C++. Below is my Lua interpreter code. This is a class that corresponds to a single Lua state, and has functions that are easier to call: The Invoke() function at the bottom is where most of the action is. #include "../le3.h" namespace le3 { Interpreter::Interpreter() : L(NULL) { L=lua_open(); luaopen_debug(L); luaL_openlibs(L); luabind::open(L); //Bind classes bind_LE3_Vec2(L); bind_LE3_Vec3(L); bind_LE3_Vec4(L); bind_LE3_AABB(L); bind_LE3_Plane(L); bind_LE3_Quat(L); bind_LE3_Mat3(L); bind_LE3_Mat4(L); bind_LE3_Transform(L); bind_LE3_Entity(L); bind_LE3_Pivot(L); //Bind global functions using namespace luabind; module(L) [ //Global functions def("Print", (void(*)(const std::string&)) &le3::Print), def("LoadModel", (Model*(*)(const std::string&, const int& flags)) &le3::LoadModel), def("GenerateError", &GenerateError), //Model class_<Model,Entity>("Model") ]; } Interpreter::~Interpreter() { if (L!=NULL) { lua_close(L); L = NULL; } } int Interpreter::GetStackSize() { return lua_gettop(L); } void Interpreter::SetStackSize(const int& size) { int currentsize = GetStackSize(); if (size<currentsize) lua_pop(L,currentsize-size); } void Interpreter::HandleError() { Print("Error: "+std::string(lua_tostring(L,-1))); } void Interpreter::HandleException() { std::string err = "Lua debugger not found."; lua_getglobal(L,"debug"); if (lua_istable(L,-1)!=0) { lua_getfield(L,-1,"traceback"); if (lua_isfunction(L,-1)!=0) { if (lua_pcall(L,0,1,0)==0) { if (lua_isstring(L,-1)!=0) { err = lua_tostring(L,-1); } } } } Print("Error: "+err); } bool Interpreter::ExecuteString(std::string& source) { bool result = false; int errorhandler = 0; int size = GetStackSize(); if (luaL_loadbuffer(L,source.c_str(),source.length(),"")==0) { result = Invoke(0,0); } else { HandleError(); } SetStackSize(size); return result; } bool Interpreter::ExecuteFile(const std::string& path) { bool result = false; int errorhandler = 0; int size = GetStackSize(); Bank* bank = LoadBank(path); if (bank==NULL) return false; if (luaL_loadbuffer(L,bank->buf,bank->GetSize(),path.c_str())==0) { result = Invoke(0,0); } else { HandleError(); } delete bank; SetStackSize(size); return result; } bool Interpreter::Invoke(const int& in, const int& out) { try { if (lua_pcall(L,in,out,0)==0) { return true; } else { HandleError(); } } catch(luabind::error& e) { HandleException(); } } }

With the approach I am describing, the top-middle, middle-left, center, middle-right, and bottom-middle images would get stretched horizontally, vertically, or both, depending on which section it is. That was you can have gradients or whatever, and they will fill the entire area of the element. The advantage is you can make your GUI once, then an artist can reskin it to make a theme appropriate for any game. This can be used to make interfaces that look more like a game interface: Code once, infinite reuse. Alternatively, you might choose to tile the edge and center images instead of stretching them.

Top left, top (stretched across), top right, middle left, center, middle right, bottom left, bottom, bottom-right.

Since PhysX 3.0 isn't released yet I will probably end up playing with both.

You don't need to run things through the GMF format. At this time, the LE3 MDL format is just GMF with a different extension. I don't know yet whether another UU3D exporter will be made for the LE3 MDL format, or whether the final format will be exactly the same as the LE2 GMF format. There's still a lot of unknowns about the needs of model files in LE3, so I can't discuss it in much depth yet.

We have three different discussions occurring in this thread. 1. Unspecified complaints about the LE2 pipeline, which I am trying to get the the bottom of. 2. Discussion of uses of UU3D as a modeling program. 3. Discussion of LE3 pipeline, which confuses me because there is no conversion step in the pipeline that the user has to worry about. GMF file get automatically converted the first time you run the editor.

3D World Studio exports directly to .gmf. There are converters in the "Tools" folder for .obj and .x.

Shouldn't you complain about that to the author of your modeling program? I know FBX and Collada are complex formats, but I don't know any other 3D formats that handle skinned animation and have as widespread support. If your modeling program doesn't support the industry standard what good is it? Is there some other format they rely upon that is widely used?

Why wouldn't they just have them in Collada or FBX format in the first place? If those aren't the standard 3D file formats, what are?

What file format would you like supported? You can use FBX and Collada. If you just say "the art pipeline sucks" that gives me zero information. I don't know why UU3D gets recommended so much. I always use the FBX converter.

So if you have a character offscreen that is far away, that you are controlling, and he walks through where a dynamic object would be if it had been loaded yet (but it hasn't), what should occur? That's just one example. You put constraints on a system when you try to do these type of things, and it gets much harder to work with, with lots of caveats and exceptions.

Would you guys really want to deal with threaded loading yourself, hard-coding each instance? Wouldn't it be better to have a mechanism built into the engine so that static models could be loaded in the background in very large worlds? This would only work with non-moving non-interacting models, like big buildings and stuff.

They removed the vehicle functionality since then. It was never that great, which is why I did my own. Newton has the absolute best rigid body solver, without question. However, we need more than just a rigid-body solver.

It's not a simple matter to add this stuff in at this point.

The waves in my video are traveling. it's basically an FFP simulation, like what Crysis uses, but this one is calculated to be looping and seamless, so the data can be pre-calculated and reused. If you look carefully in CryEngine you will be able to tell the waves are moving in two opposing directions along one axis. If you look in the far end of the pool, that indistinct ocean movement is what I was hoping to get. I think it will look good when a shader is applied to the wave data.

I like the idea of just using vector graphics because you can change the color scheme very easily. However, if you use nine images for each element, you can achieve this look, and a whole lot more. I got off track when I tried designing a GUI that had both vector and image methods you could choose from...it just turned into a mess. If I were to start a new one today, I would just stick to images instead of trying to mix vector and image graphics. That's just been my experience with GUI design. If you know for sure this is the look you want, then vector graphics are great too.

I wouldn't argue that LE2 water is better than your video you posted. LE3 water is/will be, but it takes time.

Wow, that looks horrible. What the hell, the water just bulges up for a few seconds, then flattens down? Take away the beautiful island, and people would be laughing at that. I paid to have a special fluid simulation performed and I have the wave data. I guarantee the motion will look better than that.

There is a huge difference between running a single self-contained process on another thread and designing a command set that can just be called in any order at any time. Even if I locked the threads in every single call (which would eliminate any speed gains you might get from multithreading) there's still a ton of errors the user can cause themselves.

Thanks, looks like we have a bug.

It is possible for the reference to remain in some special situations, like if the model were used in a vegetation layer, but generally yes, this will work. Source code?

Looks good.

They have some real dynamic breakage using booleans, much like how 3D World Studio works. I'm sure I could implement this with our CSG routines, with any physics library. I much prefer a real dynamic solution over pre-made fracturing. Even if the results look worse, the fact it is truly dynamic makes it much better, IMO. This works out well with our CSG editing, because you could set each brush to be "breakable" and have real breakable features. Of course, this would not handle shearing forces, so you would not have objects collapsing from the stress of removing a support, unfortunately. The best you could hope for would be that the whole structure falls over in one solid piece, with further breaks occurring at impact points. Realistically, it would probably just amount to shooting concrete off of an indestructable rebar frame, like what all the PhysX destruction does.