Jump to content
The Dark Mod Forums

Itches, Glitches & Anything Else...


Recommended Posts

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.

Link to post
Share on other sites
  • Replies 1.9k
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Since I've stumbled over the same issue (and even tracked a needless bugreport), I've just commited the following:   Index: def/tdm_mover_base.def ===================================================

That's a pretty ambitious project that will require almost every trick in the book. I can sort of envision how you might use fences, skyboxes, and archways to assist with compartmentalization but over

I'd say it is perfectly doable if you make it almost planar, or with only mild height differences. The images below show how I would do it:   See how the mountains and houses always block the view f

Posted Images

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.

Gerhard

Link to post
Share on other sites

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).

Link to post
Share on other sites

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?

Link to post
Share on other sites
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. :(

Link to post
Share on other sites

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.

Link to post
Share on other sites
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!

Link to post
Share on other sites

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. :)

Link to post
Share on other sites

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).

Link to post
Share on other sites
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? :blink:

Link to post
Share on other sites

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.

Link to post
Share on other sites
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).

Link to post
Share on other sites
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).

Link to post
Share on other sites
(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).

Link to post
Share on other sites
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 :)

Link to post
Share on other sites

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...

 

colors2xg6.th.jpg

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...