Josh

I've been playing with tags in IPB 3.2. They're actually very well implemented. That is what we will use to keep things organized in one programming forum.

Add this line in the material file: zsort=1

When you're recording a video, you often have an impulse to look around because you feel like the user will get bored. Then when you go back and watch the video, I often wish the person recording it would just leave the camera still so I can focus on the video. I noticed the same thing when I was recording my own videos.

Those day cycles scripts are getting ridiculously good.

http://www.blitzmax.com/codearcs/codearcs.php?code=2907

I was going to try moving the Leadwerks3D code into a leadwerks.leadwerks3d module, but I discovered the namespace system doesn't really work when you try to override BRL's classes. You CAN specify brl.stream.TStream or leadwerks.leadwerks3D.TStream, but you get problems when you try importing another file in your code. Even if your imported code file includes both modules and explicitly declares the variable type using the namespace, the program still can't compile. The whole module/namespace system doesn't seem to be designed like it was meant to be taken seriously. Since BMX is free updates for life, I don't really this improving. I just reverted to the last SVN commit and will continue prefixing all functions and types with "LE".

Probably the best way is to make a lot of textures that can be mixed and matched, and make the whole thing a grid with the different textures applied, at least in the areas that require a high density of different textures.

We're a few years off from truly usable hardware, too.

For real-time effects, I would modify the material texture matrices.

This is a very difficult problem because you want unique detail everywhere, but you have an enormous area to span. The problem you are experiencing are fundamental problems with the nature of real-time graphics, although MSAA might potentially help improve this. I don't know if there is a good solution.

ATI and NVidia give you a line number an error occurs on. That would be a good start if we had that, but honestly I would be shocked if it ever ran on a setup like this. Leadwerks3D will run on Mac natively.

I've never coded much polygonal modeling routines, instead focusing on constructive solid geometry. I wanted to include some tools for modifying surface normals and texture coordinates. I came up with a normal calculation routine that actually uses four different algorithms, depending on the settings specified. One thing I learned right away is you want to do away with n*n routines. That is, NEVER do this: for (i=0; i<surface->CountVertices(); i++) { for (n=0; n<surface->CountVertices(); n++) { //Write some code here } } Instead, I used an std::map with a custom compare function. The comparison function below, when used together with an std::map, allows the engine to quickly find a vertex at any position, within a given tolerance: bool SurfaceReference::UpdateNormalsCompare(Vec3 v0, Vec3 v1) { if (v0.DistanceToPoint(v1)<UpdateNormalsLinearTolerance) return false; return v0<v1; } At first I was experiencing some weird results where some vertices seemed to be ignored: I realized the problem was that my map, which used Vec3 objects for the key, were not sorting properly. Here was my original Vec3 compare function: bool Vec3::operator<(const Vec3 v) { if (x<v.x) return true; if (y<v.y) return true; if (z<v.z) return true; return false; } The above function is supposed to result in any set of Vec3 objects being sorted in order. Can you see what's wrong with it? It's supposed to first sort Vec3s by the X component, then the Y, then the Z. Consider the following set of Vec3s: A = Vec3(1,2,3) B = Vec3(2,4,3) C = Vec3(2,1,1) When sorted, these three Vec3s should be in the following order: A,C,B If you look carefully at the compare function above, it doesn't give consistent results. For example, A would be less than C, but C would also be less than A. Here's the correct compare function. Notice I added a second logical operation for each element: bool Vec3::operator<(const Vec3 v) { if (x<v.x) return true; if (x>v.x) return false; if (y<v.y) return true; if (y>v.y) return false; if (z<v.z) return true; return false; } So with that issue sorted out, the resulting code using std::maps is much, MUCH faster, although it can get pretty difficult to visualize. I think I am a hardcore C++ coder now!: void SurfaceReference::Optimize(const float& tolerance) { int i,a,b,c,v; Vertex vertex; bool(*fn_pt)(Vertex,Vertex) = OptimizeCompare; std::map<Vertex,std::vector<Vertex>,bool(*)(Vertex,Vertex)> vertexmap (fn_pt); std::map<Vertex,std::vector<Vertex>,bool(*)(Vertex,Vertex)>::iterator it; int vertexcount = 0; std::vector<Vertex> vertexarray; Vec3 normal; OptimizeTolerance = tolerance; //Divide the surface up into clusters and remap polygon indices for (i=0; i<CountIndices(); i++) { v = GetIndiceVertex(i); vertex = Vertex(GetVertexPosition(v),GetVertexNormal(v),GetVertexTexCoords(v,0),GetVertexTexCoords(v,1),GetVertexColor(v)); if (vertexmap.find(vertex)==vertexmap.end()) { vertex.index = vertexcount; vertexcount++; } vertexmap[vertex].push_back(vertex); SetIndiceVertex(i,vertexmap[vertex][0].index); } //Resize vector to number of vertices vertexarray.resize(vertexcount); //Average all vertices within each cluster for (it=vertexmap.begin(); it!=vertexmap.end(); it++) { std::vector<Vertex> vector = (*it).second; //Reset vertex to zero vertex.position = Vec3(0); vertex.normal = Vec3(0); vertex.texcoords[0] = Vec2(0); vertex.texcoords[1] = Vec2(0); vertex.color = Vec4(0); //Get the average vertex for (i=0; i<vector.size(); i++) { vertex.position += vector[i].position; vertex.normal += vector[i].normal; vertex.texcoords[0].x += vector[i].texcoords[0].x; vertex.texcoords[0].y += vector[i].texcoords[0].y; vertex.texcoords[1].x += vector[i].texcoords[1].x; vertex.texcoords[1].y += vector[i].texcoords[1].y; vertex.color += vector[i].color; } vertex.position /= vector.size(); vertex.normal /= vector.size(); vertex.texcoords[0].x /= vector.size(); vertex.texcoords[1].x /= vector.size(); vertex.texcoords[0].y /= vector.size(); vertex.texcoords[1].y /= vector.size(); vertex.color /= vector.size(); //Add to vector vertexarray[vector[0].index] = vertex; } //Clear vertex arrays delete positionarray; delete normalarray; delete texcoordsarray[0]; delete texcoordsarray[1]; delete colorarray; delete binormalarray; delete tangentarray; positionarray = NULL; normalarray = NULL; texcoordsarray[0] = NULL; texcoordsarray[1] = NULL; colorarray = NULL; binormalarray = NULL; tangentarray = NULL; //Add new vertices into surface for (i=0; i<vertexarray.size(); i++) { vertex = vertexarray[i]; AddVertex( vertex.position.x, vertex.position.y, vertex.position.z, vertex.normal.x, vertex.normal.y, vertex.normal.z, vertex.texcoords[0].x, vertex.texcoords[0].y, vertex.texcoords[1].x, vertex.texcoords[1].y, vertex.color.x, vertex.color.y, vertex.color.z, vertex.color.w ); } UpdateTangentsAndBinormals(); } Below, you can see what happens when you use the angular threshhold method, with angular tolerance set to zero: And here it is with a more reasonable tolerance of 30 degrees: You can calculate texture coordinates for a model using box, plane, cylinder, and sphere texture mapping. You can also do a pure matrix transformation on the texcoords. The editor automatically calculates the bounds of the object and uses those by default, but you can translate, scale, and rotate the texture mapping shape to adjust the coordinates. Box and plane mapping were easy to figure out. Sphere and cylinder mapping were more difficult to visualize. I first cracked cylinder mapping when I realized the x component of the normalized vertex position could be used for the U texture coordinate, and then sphere mapping was just like that for both X/U and Y/V: Box mapping is good for mechanical stuff and buildings, but bad for organic shapes, as you can see from the visible seam that is created here. Good thing we have four more modes to choose from!: You also get lots of powerful commands in the surface class. Here's a little taste of the header file: virtual void Optimize(const float& tolerance=0.01); virtual void UpdateTexCoords(const int& mode, const Mat4& mat=Mat4(), const float& tilex=1, const float& tiley=1, const int& texcoordset=0); virtual void Transform(const Mat4& mat); virtual void Unweld(); virtual void Facet(); virtual void UpdateNormals(const int& mode, const float& distancetolerance=0.01, const float& angulartolerance=180.0); To conclude, here's some other random and funny images I came up with while developing these features. I think they are beautiful in their own flawed way:

I would use the Curve() function to make the camera gradually align to match the player's direction when they turn.

I know it's been done with Windows Forms.

I'm on my Mac right now and don't have an easy way of checking your texture, but if it doesn't have mipmaps, NVidia cards will render it pure black.

AppTime returns the time at the last UpdateTime() call. This way the time value stays the same for your entire loop, until the next time update.

Your code looks right. I prefer to use abstract paths, because then it works with either pak files or plain files.

The y coordinate gets flipped when you draw to a buffer. This has to do with the way the underlying graphics API works. In Leadwerks3D, the engine will detect these cases and correct them automatically, but for Leadwerks Engine do this: DrawImage x,y+height,width,-height

BSP geometry does not require any LOD because it tends to be very low-poly. http://www.leadwerks.com/files/Level_Design_in_2009.pdf

I sent a PayPal link you can use.

Where the heck do you get a credit card that expires in 8 years?

There's two ways to do this: CSG brushes can be broken programmatically. This is nice because it requires zero pre-processing and no extra artwork preparation. The breaks are pretty simple, but they can be more complex as CPU speeds increase. In the long run, this is the right way to do things. Another option is to have an entity set to replace itself with a number of different models once a damage threshold is reached. This is how HL2 did breakages, and how PhysX still does it. It requires more work in the art pipeline, but the breakages look more realistic (although they break the same every single time, regardless of the point and direction of impact.) Neither approach deals with shearing forces, so the results will always be limited until that is addressed (which would require many times more computational power). This is why in these demos you always see breakable pieces being shot off an indestructable frame. I've seen a lot of videos where they go out of their way to hide this, but it's always the case.

The programming component remains in Leadwerks3D, and in fact will be better supported. But we have learned by now a programming SDK alone can't survive. For every programmer, there are a hundred non-programmers who have just as much money to spend. Making an easy to use visual tool was never a consideration in the past. I can't be accused of failing to provide that, because I was never attempting to. Until now, I have focused solely on performance and features, and was able to develop some nice technology. With Leadwerks3D, I am making the art pipeline and ease of use top priority, which is why I don't like hearing that people are already planning their own ways to work around the default pipeline. Your experience with Leadwerks3D will be completely different, because all those little tasks that are left to the end user in Leadwerks Engine now have a supported documented way of accomplishing them. That also has the benefit of lowering my support costs because people can just look up in the docs on how to fix a model, adjust a light, etc.

Leadwerks Engine was never designed to be a visual game design tool. It was conceived as a programming SDK for BlitzMax. It didn't even have an editor when it was first released. Leadwerks3D is being developed with a completely different approach.

MaxScript is an example of script that is useful in an editor. You can add little tools, exporters, and dialogs. However, it is my hope that when Leadwerks3D comes out people will be focused on making their games rather than reworking the tools.