Itches, Glitches & Anything Else...

[OrbWeaver 707]

Now that's surprising for me, I thought you've been coding C++ for a living. You've been coding something else before I assume?

 

Yes, I have done programming before. Most of my daily work is done in Java, but it's corporate enterprise stuff I don't give a shit about, so DarkRadiant/C++ is where I try to develop my skills in doing things "properly".

 

OpenGL? Do I hear renderer fixes up and coming?

 

I actually have a plan to test using Display Lists in the model plugin to (possibly) accelerate the drawing of model meshes, so it's possible there could be some improvement (or not, maybe this is not the bottleneck anyway).

 

For that matter, I'm just curious, maybe it's being done in PM, but did namespace leave the effort? Haven't seen him posting since the first few times.

 

I haven't heard from him either, I suspect he has not completely finished with GtkRadiant so he may still have some work to do there.

[sparhawk 17]

The best book on math that I ever found was "Geometric Tools for Computer Graphics". I have several books but I liked this the most, because it's pretty complete, and the author really goes also into detail and explains a lot of the background as well, so you can even learn a lot if you don't have to much background, or forgot a lot of it. Also you can reach the author via email and he was very helpfull and responsive.

 

For OpenGL I was using "OpenGL superbible"and "OpenGL Reference Manual" which I also found rather goog, but they are not so much on tutorials. More a complete overview and quite handy to have around when doing OpenGL coding.

[New Horizon 557]

Just tried to run dr in windows again, still get the pango error. So I'm guessing I just need to install a pango package of some sort? Is there a specific build that I need?

[greebo 130]

No, I think the most recent stable build will be enough. Try this ftp://ftp.gtk.org/pub/pango/1.14/win32/pango-1.14.9.zip and copy the DLLs from the bin/ folder into your DarkRadiant installation folder. Hopefully this will do the trick (if yes, I'll update the wiki article).

[OrbWeaver 707]

There is also a copy of libpangowin32-1.0-0.dll in the DarkRadiant installation folder from the official release.

[New Horizon 557]

Getting a fun new error now.

 

"The procdure entry point g_intern_static_string could not be located in the dynamic link library libglib-2.0-0.dll"

 

No idea why I have such a hard time getting this to work on windows. lol Gah

[OrbWeaver 707]

Looks like a DLL version problem, the one packaged with 0.8.1 is libglib-2.0-0.dll

[New Horizon 557]

Looks like a DLL version problem, the one packaged with 0.8.1 is libglib-2.0-0.dll

 

Sorry, that was a typo on my part...it should have read libglib-2.0-0.dll

[New Horizon 557]

Just wanted to bump this up, in case anyone has some ideas. I would really like to get this working.

[greebo 130]

Try this: Take the latest release version 0.8.1 and install it somewhere in case you haven't done this yet. Then take the DLLs from this release and pack it into your install/ folder (where you checked out the SVN stuff). Does this resolve anything?

[New Horizon 557]

Try this: Take the latest release version 0.8.1 and install it somewhere in case you haven't done this yet. Then take the DLLs from this release and pack it into your install/ folder (where you checked out the SVN stuff). Does this resolve anything?

 

Sadly not, this is the way I've had it setup all along.

[greebo 130]

That's strange. I will have to get to a "clean" computer without my build environment, so I hopefully can complete the tutorial and see what might be missing.

[OrbWeaver 707]

You also need to copy the lib and etc directories, as well as the DLLs. Beyond this, I can't see what the problem could be -- if your install directory is the same as the official release, the application should work, unless there is something screwy with your compiler setup.

[New Horizon 557]

You also need to copy the lib and etc directories, as well as the DLLs. Beyond this, I can't see what the problem could be -- if your install directory is the same as the official release, the application should work, unless there is something screwy with your compiler setup.

 

Ahhh, that fixed it. Thanks orb. Was that listed in the wiki? I don't recall seeing it there.

 

Thanks guys. I'm finally able to build and test on windows!

[greebo 130]

No, it's not listed in the wiki, because I intended to describe an installation without all that copying of DDLs and stuff from an existing DarkRadiant installation.

 

If I don't find a way around it, I will fall back to the steps you just described.

[greebo 130]

I just wanted to drop a note here that this entire scene::Instance stuff sucks, sucks and sucks even more. (*rant*)

 

Now there are BrushInstances and PatchInstances. That's fine with me, because they can be identified with a scene::Path (that's a delicious typedef Stack, a so-called "unique" key - as if a simple int didn't do the trick...).

 

The problem starts with FaceInstances, because it turns out that they aren't any scene::Instances at all, they just happen to be named Instances. Hence they don't have a scene::Path and there is no possibility to check whether they are already in my list of selectables or not.

 

Something has to be done here, but if we start to change this part of GtkRadiant, I fear that we can rather rewrite a good part of the core app...

 

Conclusion: the TexTool will probably not be able to keep track of its selections, because of this half-assedness with FaceInstances (apart from some ugly hacks I couldn't think of another way, therefore I'll leave it at that).

[OrbWeaver 707]

That's fine with me, because they can be identified with a scene::Path (that's a delicious typedef Stack<NodeReference>, a so-called "unique" key - as if a simple int didn't do the trick...).

 

It's supposed to be more than just a key, it also allows you to get the parent entity and stuff. Of course Stack<NodeReference> is stupid, it should be std::list<boost::shared_ptr<scene::Node> >.

 

To be honest I don't think the design of the Node/Instance system is that bad, although its implementation leaves a lot to be desired.

 

The problem starts with FaceInstances, because it turns out that they aren't any scene::Instances at all, they just happen to be named Instances. Hence they don't have a scene::Path and there is no possibility to check whether they are already in my list of selectables or not.

 

Yeah, faces aren't actually part of the scenegraph, although I guess it's possible they could be. It would no doubt be a rather large job to change this however.

 

Something has to be done here, but if we start to change this part of GtkRadiant, I fear that we can rather rewrite a good part of the core app...

 

There's a good part of the core app?

[greebo 130]

Well, I guess I did not entirely understand what the difference between node and instance is, then. Is the intention of using a Stack or std::list that each instance should know its parent (even multiple parents)?

 

Are there any scenegraph objects that have more than one parent node? Are there some school-examples of how a scenegraph should look like? I'd be keen to know, I guess I will start googling.

[OrbWeaver 707]

Well, I guess I did not entirely understand what the difference between node and instance is, then. Is the intention of using a Stack or std::list that each instance should know its parent (even multiple parents)?

 

The idea is that a Node is only stored once, whereas you can have multiple Instances of that node. For instance, if you create a model and duplicate it 10 times, you should have a single Node but 11 Instances, each of which has a reference to the Node. This is supposed to save memory (since the mesh will only be stored once) and possibly have performance benefits, but I don't know how well it is implemented (in particular, I don't know under what circumstances a single Node is Instanced more than one, for example, if you add two func_statics and set them to the same model, do they share a Node or not?).

 

Are there any scenegraph objects that have more than one parent node? Are there some school-examples of how a scenegraph should look like? I'd be keen to know, I guess I will start googling.

 

I think there are only three levels: Root, Entity, Primitive. It might be possible to have Face as a sub-node of Brush, but this could be a substantial redesign.

 

Note however that the similarity between Radiant's "scene graph" and the real definition of a scene graph is fairly tenuous. A real scenegraph would have many levels, with each level propagating its transformations and other properties down to its children (think of Blender and its parenting hierarchy). Radiant's version is little more than a "map dump" which stores the map data in the same way the .map file does, with very little hierachy and absolutely no spatial information (which is vital for good performance).

[greebo 130]

The idea is that a Node is only stored once, whereas you can have multiple Instances of that node. For instance, if you create a model and duplicate it 10 times, you should have a single Node but 11 Instances, each of which has a reference to the Node. This is supposed to save memory (since the mesh will only be stored once) and possibly have performance benefits, but I don't know how well it is implemented (in particular, I don't know under what circumstances a single Node is Instanced more than one, for example, if you add two func_statics and set them to the same model, do they share a Node or not?).

I get the idea of memory-saving and such, but I believe that this is not the way Radiant works, because the duplicated items can always be changed once they are duplicated (entity key/values, shaders, whatever).

 

The memory-intensive data like model meshes and shader images shouldn't be stored in the scenegraph instances in the first place, should they? This should be the job of some sort of cache (like the recently implemented GLTextureManager) that keeps track of the "large" data junks.

 

I'm sure that this system can be simplified a lot without the distinction of nodes and instances. Just scene::Nodes in three flavours (as you said: Root, Entities and Primitives) with a defined interface for rendering, selection and manipulation. No multi-parenting or node-sharing.

 

(Could well be that I'm just imagining this to be more simple than it is.)

 

A real scenegraph would have many levels, with each level propagating its transformations and other properties down to its children (think of Blender and its parenting hierarchy).

(Just saw your edit)

 

Funny, this is exactly the way I did implement the "mini-scenegraph" of the TexTool. I have a raw definition of a so-called TexToolItem with some default methods. Each TexToolItem is allocated via boost::shared_ptrs and stores its own vector of TexToolItem children (I think that's an n-tree, isn't it?). Upon selection, rendering or transformation each TexToolItem propagates the according calls down to it's children (the default methods being defined as virtual TexToolItem::transform(), so that the implementations can override it by their own methods).

[OrbWeaver 707]

(Could well be that I'm just imagining this to be more simple than it is.)

 

No, you are absolutely right. If nodes are never shared, there is no point in having instances, all you have is a simple n-tree (as you pointed out) which only needs a single Node interface for insertion and traversal (other stuff like selection would be defined through separate interfaces, as it currently is).

[greebo 130]

Anyway, it won't make it in any of the near-future releases I guess. (Except the case one of us gets fed up enough with the current system... )

[greebo 130]

Mathematics for 3D Game Programming & Computer Graphics

 

It will take a while till they've been shipped here from the U.S. but I look forward to them. Hopefully I will have time to read them as well next to writing my diploma. ;-)

The above book just arrived here in Austria. I ordered it from an private U.S. seller at Amazon's marketplace on Monday and 5 days later it's lying in front of my door. Even faster than the book I ordered directly from Amazon.com

[sparhawk 17]

Funnily enough, books shipped from the US sometimes arrive faster then orders from some ebay members directly here in Germany.

[SneaksieDave 40]

Didn't want to re-open the existing closed entry, so I'll just ask this here. About the entity colors! And the fact that they are stored in the DEF files. I realized why they struck me as so hard to see all of a sudden (duh, all I had to do was check DoomEd and compare *smacks head*). Note the display of the same items in DoomEd and DarkRadiant (yes, I've since lightened my DR background a bit to match better, and it makes the dark green a little easier to read). These are default, unchanged, and unselected.

 

So again, do we visit this? Are the colors really being used properly in DR from the DEFs, or are they not handled and instead using a default value? More investigation draws me forward...