Jump to content
The Dark Mod Forums

Itches, Glitches & Anything Else...


Recommended Posts

Just sent off for a couple of gigs of RAM as I'm getting lockups with DR plus Doom plus a few other programs running all at the same time with 500Mb RAM.

 

I've noticed big missions take quite a while to load. Presumably most of this is processing time as the data is read in. In memory is this data in such a form that DR could have its own save format which would be the processed data? This would use more disk space but load and save faster. The mapper need only save as a map file to test. Just a thought. Not sure if there is any real value in that. Probably depends how often mappers open and save without actually testing.

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

You're sure that's not your map file? The rendering code has hardly been touched, it should even be faster when rendering models.

 

Expect it to get slow when exceeding 1500 primitives, depending on your CPU power. The bonehoard with its 4500 primitives "runs" really slow in DarkRadiant. Cubic clipping might help here a bit.

Link to post
Share on other sites

Actually I noticed what is causing it last night. In the old version the xy zx and yz views had to be zoomed in quite far for the 3d view to run smoothly. However in this new version you have to zoom in even further for it to run smoothly. For some reason the 3 2d views are lagging the program more-so than the 3d view it would appear.

Link to post
Share on other sites

Ah yes, that seems logical. More views with many visible objects mean more rendering work to do.

 

Thinking about this, it should not be necessary to redraw every single orthoview if you move the camera (this is done currently to update the small blue camera icon in the orthoviews). If we make this update deferred, we could boost the performance a bit, I guess.

Link to post
Share on other sites

No, nothing has changed in the camera handling.

 

Still, I think we can actually gain a LOT of performance if we make the updating of the small blue camera icon deferred. Currently, every single camera move (even if it's only a pixel) triggers a complete redraw of all orthoviews, just to update the angles of the icon.

Link to post
Share on other sites

I always have the three ortho windows open and the 3D camera view. I noticed once a quite extreme slowdown, even with my small watermill map. In fact the app got so slow that you could barely do anything. I don't know what I did though, because it has gone away. I think I tried to switch on realtime rendering and this was extremly slow. Otherwise, it works quite smooth. I even let D3 run in the background when I test a map, and I still don't see any noticable lags.

Gerhard

Link to post
Share on other sites

How many lights did you place in your map when you had the lighting mode active? This can seriously slow down DarkRadiant.

 

A map of the size of test_watermill.map shouldn't have any noticeable slowdown, so I suspect that the number of lights was the reason.

Link to post
Share on other sites

Sorry to get off the performance topic but I just thought of something again. Would it be possible to make it so that when you rotate a texture it rotates from the middle of the brush instead of having the texture move on its axises like it currently does when you rotate a texture?

Link to post
Share on other sites

I think it's possible, although I don't know if it is easy to achieve. The way it works for brushes is that the 3D vertices are transformed into texture space, some sort of one-way transformation, not the other way round, that's why it sometimes looks so weird. You rotate the whole texture plane around the origin = .

 

Hm, I think it could work if I'm able to find a pivot point in texture space and rotate about that point using the right matrix, although I'm not sure if that works with the brushprimitive texdef.

 

Did you try to "normalise" your texture before you rotate? This should make the rotation behave a bit better, as you move the face closer to the 0,0 origin in texture space. Not a remedy of course.

Link to post
Share on other sites

If you're really interested in what is going on when you do things in the Surface Inspector, just open the Texture Tool and see what happens. This can help to explain much of the weirdness. :)

Link to post
Share on other sites

haha, oneeeee last thing I'd like to report today :) It's rather a tiny annoyance as opposed to a potentially large bug. When you try and open the texture window by pressing the shortcut T multiple times it doesn't unminimized the box, rather it just moves the small box to the center of the screen.

Link to post
Share on other sites
Was this still with the hi-poly version of your watermill or did you already use the reduced one?

 

I think it was with the highpoly. But still, the map is pretty small and contained nothing except the wheel itself, so I shouldn't have such an extreme lag. But as I said, it didn't happen so far anymore.

Gerhard

Link to post
Share on other sites
haha, oneeeee last thing I'd like to report today :) It's rather a tiny annoyance as opposed to a potentially large bug. When you try and open the texture window by pressing the shortcut T multiple times it doesn't unminimized the box, rather it just moves the small box to the center of the screen.

I just held down T for several seconds, I can't reproduce this. :mellow:

 

As for the performance issues: I just realised, there is already an option to turn off the XYView update when the camera moves. Open Preferences > Orthoview and disable Update Views on Camera Movement. This should give you a performance gain.

Link to post
Share on other sites
As for the performance issues: I just realised, there is already an option to turn off the XYView update when the camera moves. Open Preferences > Orthoview and disable Update Views on Camera Movement. This should give you a performance gain.

Wow! Major performance difference here. I only use one ortho view plus the cam, and it even helped tremendously with that. Apparently (since cam movement is not even locked to ortho!) just updating the view icon does in fact force the view window to redraw, and even with one window that's enough to change the framerate in the cam from about 10 (though it feels even lower) with the setting on, to about 23 (i.e., completely smooth) with the setting off!

 

Thanks for bringing this issue up, and finding a nice solution, guys. :)

Link to post
Share on other sites
I just held down T for several seconds, I can't reproduce this. :mellow:

 

As for the performance issues: I just realised, there is already an option to turn off the XYView update when the camera moves. Open Preferences > Orthoview and disable Update Views on Camera Movement. This should give you a performance gain.

 

GIANT performance gain! :D This should be included in a sticky or something it helps a huge amount. Bonehoard would run fine with this option enabled! This is how i reproduce the problem I described.

 

Open DR

press T

minimize the texture window using the line on the top right

press t several times, the window will not unminimize.

 

Also I upgraded to 3 gigs of ram today from 1 gig, minor performance gain in DR before enabling that option, just a fun fact :)

Link to post
Share on other sites
Open DR

press T

minimize the texture window using the line on the top right

press t several times, the window will not unminimize.

 

That would be a window manager issue I suspect, not a DarkRadiant issue. When I try this on Linux the window does unminimise.

Link to post
Share on other sites

I encountered something very strange today. I have several leaks in my map and i have been going through finding them and fixing them. I attempted 3 compiles but it didn't work but I used the pointfile to fix it. After opening the third pointfile this is what I saw:

 

untitledrp1.th.jpg

 

I don't know what happened, but it seems that all non-brush objects had been extended far out into the reaches of nowhere. I don't know if this is possible to recreate.

Link to post
Share on other sites

I need to talk about leeks to, but not today. My real problem is that i can't make the transaction from Domedit to darkradiant, i just can't, everything in Darkradiant seems so more confused, i think i need help, please, whats wrong with me?

Link to post
Share on other sites

I just had the same problem happen to me again. It happens when I have DR open, and do this several times:

 

1)Save map and minimize

2)Start up doom3 compile so it says found leak

3)quit doom3

4) maximize DR and load pointfile

5)repeat for multiple holes in map.

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