Josh

When people describe voxel terrain, what they usually mean is a modeling technique that creates a bunch of cubes, and then uses the marching cubes algorithm to turn that into polygonal geometry. It is possible to render pure voxel data, but for practical use it would require special hardware that hasn't been invented yet.

Voxel terrain is all a unique mesh. Technically, the engine can do that right now, because you can model a voxel-based mesh in 3ds max or something and render it in the engine. The result is the same. Using voxel terrain for the whole terrain is a bad idea for the reason above. I don't think you realize how fast the current terrain rendering system is. You can have a terrain up to 33 million triangles. This would never be possible with a purely voxel-based system of unique geometry.

When I started LE2 everyone thought I was crazy for requiring a shader models 3 GPU. Two years later, 85% of Steam users can run the engine. Yes, LE3 will feature tessellation. To what extent this removes the need for LOD, I can't say until I try it. You will still want LOD for animated characters, because it can be used to remove bones as well as just triangles.

I've made some progress with a new ocean water implementation. It was made by running a fluid simulation and recording the data. There are still some challenges left to make it work in LE3, but I think the results will be right. The quality is very good.

If you come across any programmers that would be good for writing the GUI, let me know. It's not a mind-bending task, but it needs to be done by someone who has written a GUI before. It has to be written in C++ so that everything can access it. In fact, this is one of those things where I can just write out the complete command set and documentation first, and then let another programmer write the actual code.

Try/catch isn't a problem, but there's simply no way to use the Buffer() constructor to create an OpenGLBuffer. I could do something like this: Buffer::Buffer() { this->internalbufferclasstheuserneversees = GetGraphicsDriver()->CreateRealBuffer(); //Creates some OpenGL-specific class } But that is an incredible workaround just so constructors can be used to do something they weren't designed for.

I have an idea. It's funny when your design just perfectly fits something you did not originally intend, but it's as if it was meant to be.

Roland, that is pretty much how it works now, although I am calling it a GraphicsDriver. So I guess we have thoroughly thrashed out the reasoning why constructors really are not very useful?

I thought the graphics were just "stylized" to look that way.

There would be no reason to cull the hidden cubes, since calculating whether they were visible or not would take more time than just drawing them.

What about this game are your specifically trying to recreate?

This is how things currently work: class Shader {}; class OpenGLShader : public Shader { GLenum glprogram; }; class DirectXShader : public Shader //purely theoretical for now { DXShader dxshader; // I made this up }; Are you suggesting I do this?: class Shader { GLenum glprogram; DXShader dxshader; }; class OpenGLShader : public Shader {}; class DirectXShader : public Shader {}; I don't think try/catch will work across languages, i.e. C# try/catch is not going to catch C++ exceptions.

I love your site. Be sure to make your feature requests for LE3 for anything that will help you.

ArBuz is correct. The extended classes also contain different attributes. For example, the OpenGLShader class has an attribute "int glprogram" which a DirectX shader class would not have. Maybe it would be nice to use different name spaces for each class like this: Mesh* mesh = Mesh::Load(); Material* material = Material::Create(); Although it's not really clear to me why Mesh::Load() would be any better than LoadMesh().

They're coming out with a new add-on, but it will require additional work to make it do what I want.

Another problem with constructors: This returns an OpenGLShader object when the OpenGLDriver is in use: Shader* shader = graphicsdriver->CreateShader(); This would just create the base Shader class, which has no actual code in it that makes a shader work: Shader* shader = new Shader(); You would have to do this: Shader* shader = new OpenGLShader(); And now your code becomes specific to one graphics driver.

In LE3, there's just one .shader file you have to worry about, which will internally specify vert/frag/geom/tess shaders for OpenGL or DX. The material properties will show how many textures should be used, and what they should do, and you will just drag textures onto the thumbnail. I can probably add some shader-defined controls for uniform values.

Yes, and we'll have something like this set up within a month. You'll be able to look at your account and download products, and hopefully have your reg keys stored. I am also attempting to create a community market where you can just sell any items you want without my approval, basically like Turbosquid. I'll have more information as it develops.

You should be all set now.

Wouldn't you need to check to see if LoadMesh() returns NULL anyways? Of course, we have the problem of worrying about how this is going to work with Lua and other languages.

Please check the .......tic.co.uk email address.

I investigated a custom skin and some stuff, and actually came to the conclusion that the default Windows/Mac GUI is the best, because everyone immediately knows how to use it.

Yes, most commands will have overloads like this: SetPosition(x,y,z) SetPosition(Vec3) For inputting floats, the default function will be to send the float values, and then internally the overloaded functions will just call that, i.e.: void Entity::SetPosition(const Vec3& position, const bool& global) { SetPosition(position.x,position.y,position.z,global); } LuaBind works nicely with C++ and allows function overloading, something that was not possible with Lua in LE2, so in Lua you can do this: entity:SetPosition(1,2,3) entity:SetPosition(entity2.position) x = entity.position.x After reviewing the alternatives, I am 100% happy with Lua. It works really well together with C++, and it runs on everything. I agree, the -> separator is ugly and inconvenient, but that's really a complaint of the C++ language itself. When Codewerks arrives, you'll be able to produce the same executables with the same C++ compilers, using a saner syntax.

I'm not satisfied with the simple gradient approach some people have used. I want correct atmospheric scattering ala Crysis, and will be hiring somebody to implement that specific code, rather than messing with it myself. FYI, I have made progress with ocean water via a third party developer I am working with. I don't know for sure if it will work yet, but it looks really good. I am having good results by seeking out those people who already have the specific knowledge I am looking for. If I can find one person who did a Master's thesis on one effect, then it's a lot more efficient than developing that myself. Using C++ makes that a lot easier because everyone is on the same page at least. Heh, can you believe I am a C++ coder now?

That's an idea. It's a pretty fundamental change in design. Typically, you would code in such a way that your program can handle missing files, etc.