greebo

I'll check it out right now, I'm still compiling my own build. What I can imagine is, that the brush maybe is defective. It looks like this is a seven-sided brush and there are two faces that are parallel to the xy-plane, maybe there are bogus plane definitions in there. But as the leaks are absent in the original file, this may of course be wrong...

Thanks guys I wouldn't call it a major update (from looking at the things Orbweaver does to the code), but obviously it's a popular one, which is nice.

Now, this is getting tiresome! I've tried to figure out for 2 hours now how to load a image, but the damn thing just doesn't get loaded... The GlobalTextures().capture() method returns an q_texture object with texture_number 0 and tells me that "the image couldn't be loaded", but still returns a non-NULL pointer, which makes it hard for the calling function to determine whether the operation was successful or not. It's really frustrating - there are tons of capture(), realise() and whatever methods calling each other and most of them are buried within some cpp-File without a proper interface. And this is giving me the creeps: typedef HashedCache<TextureKey, qtexture_t, TextureKeyHashNoCase, TextureKeyEqualNoCase, TextureConstructor> qtextures_t; I think I will expand the IShader interface by methods to create new shaders. The only place where Shader objects are allocated is the Shaders plugin (of course), but other plugins don't get a real chance to do it, or I'm missing something vital.

Don't know yet, I'll have to look through the logs, as my web-based traffic tool seems to list outdated statistics, but I assume that it's ok. I will drop a message as soon as it's getting out of hand.

Ok. Shall I merge the current version with the trunk or do you suggest to wait until it's feature-complete?

This is already implemented , although at the moment only valid shaders (those in the material files) are allowed. I'll have to figure out how to create actual Shader objects out of image files chosen from a file dialog (which I have to create as well with a Registry Connection for the Preference Dialog).

I've implemented the blend functions for the image overlay, the image's transparency can now be adjusted as well:

This is my progress so far, I've been able to overlay an arbitrary shader image over the background (currently, it's stretched to fit the window dimensions, which the user will be able to change via the preference settings). If things go well, I will be able to finish this soon.

I opened a new branch with the Overlay plugin, but I'm a bit stuck when it comes to do the actual OpenGL drawing. Below is my render function. It basically creates a new displaylist and sends the quad coordinates. // OpenGLRenderable implementation, back-end render method void render(RenderStateFlags state) const { // Create the temporary list // (TODO: make this a class member and construct the list only once) int _displayList = glGenLists(1); glNewList(_displayList, GL_COMPILE); glBegin(GL_QUADS); for (VertexList::const_iterator i = _quad.begin(); i != _quad.end(); ++i) { glNormal3f(i->normal[0], i->normal[1], i->normal[2]); glColor3f(1.f, 0.f, 0.f); //glTexCoord2f(i->texcoord[0], i->texcoord[1]); glVertex3fv(Vector3(i->vertex)); } glEnd(); glEndList(); glCallList(_displayList); // Delete the list glDeleteLists (_displayList, 1); } The vertices, normals and texcoords (in this order) are stored in a std::list of ArbitraryMeshVertex structure: _quad.push_back(ArbitraryMeshVertex(Vertex3f(-100,-100,0), Vector3(0,0,1), TexCoord2f(0, 1))); _quad.push_back(ArbitraryMeshVertex(Vertex3f(+100,-100,0), Vector3(0,0,1), TexCoord2f(1, 1))); _quad.push_back(ArbitraryMeshVertex(Vertex3f(+100,+100,0), Vector3(0,0,1), TexCoord2f(1, 0))); _quad.push_back(ArbitraryMeshVertex(Vertex3f(-100,+100,0), Vector3(0,0,1), TexCoord2f(0, 0))); Problem is, I don't see anything. There must be something I miss and I don't know what it could be. These changes are already committed to the overlay branch - could you give me a hint what to do next?

I contacted my ISP about the recent outages, and they told me that the issue should be resolved. According to them it was a problem with some "international carrier" that most of the Austrian providers use for the traffic to Germany. Let's hope the problem is gone now.

It would be nice to have a comparison of these two implementations, so I would appreciate seeing your version too.

Namespace is planning to upgrade the renderer, isn't he? I know that the new render system won't be finished tomorrow, but wouldn't it be redundant to look into this if the render is to be reorganised anyway?

I started looking into it, but don't hold your breath about it. It definitely won't make it into DarkRadiant 0.8.0, maybe next release.

Ok, I'll try it out. Currently, the plugin.cpp file contains a GlobalOverlayModuleRef in its dependencies, I will commit a reverted version. edit: done.

I've committed a first draft of a plugin that should handle the orthoview image overlays. It's not functional yet, should I stop working on it till 0.8.0 is released or should we just omit shipping the dll with the package? It's not relied upon by the main code at the moment.

Congrats! This was kind of tough or at least tiresome I guess. Are there any other issues left that have to be resolved before 0.8.0?

This is resolved now. Sort of, to be precise, because this appears to be caused by a bug in MySQL that has recently been fixed (in version 4.1.22, but the server is running 4.1.21 ). The workaround has already been posted on the Mantis website.

You're right, this doesn't seem to work. I'll have a look.

I moved the UndoSystem into its own module. One piece less in the main Radiant code...

Oh well, I will have to try again tomorrow morning...

Really, can you still add issues? There is no max user count that I know of. Maybe this is a backbone problem, but in principal the internet is designed to work around such network outages. The server is located somewhere in Germany, I think, and Orbweaver is connecting from the UK, whereas I'm trying to reach it from Austria. Strange.

Me neither, and this is frickin' annoying. The site never had much downtime and I always was happy with it, but this is already the second outage (yesterday evening and now). If it doesn't get better till tomorrow I will contact my ISP to get it sorted out. I don't expect that it will be working till tomorrow morning, though. If everything goes bad, we'll have to look for some other hosting, but I'll try to stay optimistic...

SneaksieDave, do you want to submit this to the bug tracker? (I admittedly could do this myself, but I want to get you introduced to the tracker ). http://bugs.angua.at/

Off it goes then

What about the files radiant/glwidget.cpp & glwidget.h? The header file is empty and the stuff in glwidget.cpp appears to be not used anymore (I commented everything out and DarkRadiant is still running fine, it seems). As I'm not very familiar with the GTK GL methods: is it safe to remove this / is this already replaced by other classes?