DR and its shifting planes

[Bikerdude 3736]

A quick test and it looks like the texture issue has been fixed, but -

• map and texture loading speed has fallen through the floor.
  
• but conversely re-loading textures is faster than before, but the first time you do it the ortho-screen is black until you click into it, then subsequent shader reloads its fine.
  

[grayman 2697]

I'm seeing some of what Biker's seeing:

 

- texture scale issue is fixed (thanks!)

- all map loads are at least 5x slower than before

- the first time a map is loaded, the slow map load time is followed by a very long texture load time

- subsequent texture loads when switching maps are almost instantaneous

- I'm not seeing the black ortho screen Biker sees

 

So wrt texture loading, it used to be quick for the initial load, then minutes for subsequent loads when switching back and forth between maps. Now it's the reverse: slow initial texture load and immediate subsequent loads.

[OrbWeaver 450]

I was concerned that performance might suffer as a result of my latest change, since the default texture scale is looked up a lot more frequently in order to get the correct value. I already have an idea as to how this issue might be alleviated, which will hopefully turn out to be effective.

[grayman 2697]

I've been editing since my recent post, and I just switched to another map to grab something, came back to my WIP, and suffered the long texture load time.

 

So I guess the immediate texture load times I was seeing a couple hours ago were only there because my session wasn't that old. Now that it's older, I'm back to seeing what I've seen since last summer: long load times.

[OrbWeaver 450]

The latest builds should fix the performance regression with the last change. Any pre-existing performance issues will still be there however (I have also seen the very long "Loading textures" stage when trying to open cath.map).

 

[64-bit] http://darkradiant.s...t-1.7.3-x64.exe

[32-bit] http://darkradiant.s...t-1.7.3-x86.exe

[Bikerdude 3736]

The loading speed is back to normal now, thanks Orbs.

[grayman 2697]

The map loads zippity-doo-dah and so does the initial texture load.

 

If the texture load slows down later in the session (switching maps) I'll just continue with my workaround: restart DR and load the new map.

 

Which begs a question: if I'm working on one instance of my map, and save it under a new name, then ask DR to load the previous version, I'll get the slow texture load. Since the two versions of the map use the same texture set, why does DR think it has to reload them all, and what is it about the load process that makes it slow?

 

Thanks, Orbs.

[OrbWeaver 450]

Which begs a question: if I'm working on one instance of my map, and save it under a new name, then ask DR to load the previous version, I'll get the slow texture load. Since the two versions of the map use the same texture set, why does DR think it has to reload them all, and what is it about the load process that makes it slow?

 

Not a clue. I have seen similar behaviour, with the Loading Textures phase varying from just annoying to thinking the application has probably crashed.

 

Unfortunately I haven't yet found any good profiling tools that can cast any light on this (i.e. free, and available for Linux and/or Windows), and random pausing didn't show any obvious culprits. I almost wonder if it's worth trying to get DR building on Mac so that I can use the awesome performance analysis tools that are provided with the Mac OS SDK.

[Bikerdude 3736]

How much would a reasonably priced "profiler app" cost..?

[Serpentine 127]

How much would a reasonably priced "profiler app" cost..?

 

Generally nothing, they are usually part of larger collections of software which either cost a load, or cost nothing.

 

I've used gpreftools + KCacheGrind a bit, maybe a heavy but rather good for my needs. A big advantage of gpreftools is it works happily with clang, which is handy to have in conjunction to clang's static analysis and other tools.

 

There are also the Intel tools for linux, which are free for noncommercial use afaik. Never tried profiling with them, but taaaki should have some experience.

[Bikerdude 3736]

I only asked in that if it was around the £20 mark I would just buy it for orbs.

[OrbWeaver 450]

I only asked in that if it was around the £20 mark I would just buy it for orbs.

 

That's a nice thought, but if they were that cheap I probably would have bought one myself by now.

 

There are also the Intel tools for linux, which are free for noncommercial use afaik. Never tried profiling with them, but taaaki should have some experience.

 

I've seen a couple of mentions of VTune being free for non-commercial use, but I can find no reference to it on their site. The only "free" option they seem to offer is a 30-day trial of the commercial product (which might actually be sufficient for identifying this issue if it is not too complex).

 

Linux has got some new built-in profiling tools in the form of perf, but although it looks very promising, it doesn't seem to produce the required level of detail (in the callstack tracing area) to really track down an issue. There are also the Google performance tools which need to be linked into the profiled application, but I haven't yet seen what kind of output they produce.

[Serpentine 127]

Linux has got some new built-in profiling tools in the form of perf, but although it looks very promising, it doesn't seem to produce the required level of detail (in the callstack tracing area) to really track down an issue. There are also the Google performance tools which need to be linked into the profiled application, but I haven't yet seen what kind of output they produce.

 

Yeah, gpreftools is the Google Performance Tools (and not gnu/gtk - annoying naming!). The output is fairly good, and KCacheGrind accepts it as a supported input format, making it a lot easier to work with. I've not used it extensively, but the combo worked well enough for me in the past.

 

I'll get Taaaki to reply about the Intel tools, I know he's been using them to fix up leaks lately, not entirely sure about VTune tho.

[taaaki 57]

I'm busy using the non-commercial license for Intel C++ Composer XE 2013 (includes C/C++ compiler, Amplifier [new name for VTune], Inspector and Advisor + all the performance and threading libs). You can get to it here: http://software.intel.com/en-us/non-commercial-software-development

 

You can only use it for projects where you receive no income for your efforts.

 

If you get the hang of the tools, they can be really useful (far better than many of the free tools). Amplifier/VTune is the profiler, Advisor looks for parallelisation opportunities and Inspector is used to detect memory and threading errors.

[Tels 267]

There is also oprofile on Linux which can profile the entire system. The trick is here to remove the profiling of the kernel/libc and only capture your program.

 

Server seems to have hickups, but it should be described here:

 

http://wiki.thedarkm...title=Profiling

[OrbWeaver 450]

Yeah, gpreftools is the Google Performance Tools (and not gnu/gtk - annoying naming!). The output is fairly good, and KCacheGrind accepts it as a supported input format, making it a lot easier to work with.

 

I'm busy using the non-commercial license for Intel C++ Composer XE 2013 (includes C/C++ compiler, Amplifier [new name for VTune], Inspector and Advisor + all the performance and threading libs). You can get to it here: http://software.inte...are-development

 

I'll check these options out, thanks.

 

There is also oprofile on Linux which can profile the entire system.

 

oprofile is what I used to use, and it does give good information. Unfortunately it seems the Debian maintainer has gone MIA and the package has therefore been removed from Debian/Ubuntu, but getting it compiled from source would be an option if needed.

[Sotha 1905]

Oh noes! I started using DR version (1.7.3 x86 Jan 6. 2013 13:16:40) as the shifting planes problem was corrected, right?

 

This is worldspawn brushwork, not fs. It was fine last time I looked it and now it is like this:

 

Grid snap

 

So planes are now shifting on worldspawn brushes?

 

EDIT: every slanting worldspawn geometry piece is corrupted like this. The directs are fine.

 

EDIT2: bashing save button does not cause it.

 

EDIT3: repeated save/load cycles does not seem to cause it.

[Sotha 1905]

Okay, got it.

 

I snapped things back into place and repaired the brushes that disappeared manually. Initial situation:

 

Then I simply selected the brush and moved it some 500 units towards right.

 

Observation:

See how the selected object is no longer nice solid 8x8 units in dimensions, but its shape got corrupted by the movement!

 

Slanted worldspawn brushes are corrupted by simply moving them around!

 

EDIT: It also happens like this:

1) nice clean worldspawn brush, 8x8 units.

2) select, right click, make into func_static

3) the object becomes into 8x7.99998 unit func_static.

 

EDIT2: Each movement of the object seems to corrupt the worldspawn object a little more:

1) Start 8x8 unit piece

2) move once. One dimension switches to 7.9998.

3) move twice. 7.99995.

4) Ten moves. 7.99968

 

EDIT3: Only slanted objects are affected. Rectangular objects are not changed at all.

 

People working with slanted pieces should be extra-careful! .Ase exporting is still a good idea for complex pieces.

[Obsttorte 1440]

I've observed little changes like these in DR 1.7.2, too. I don't think it has something to do with the changes.

 

But that such corruptions grow with each movement is something I didn't notice before (maybe because I don't move my ws brushes over and over again ). Beneath the .Ase exporting I normally use vertex drag mode -> select all vertices -> snap to grid to handle such things.

[grayman 2697]

I hadn't noticed this problem, but I can confirm that it's happening. If I repeatedly move an angled worldbrush across the width of the map, it gets smaller and smaller with each move.

 

This needs to be addressed. Perhaps it's a side effect of the recent changes.

 

Edit: Selecting vertices, and moving them across the map does not suffer from this problem.

[Tels 267]

It is probably a floating-point error accumulating.

[Sotha 1905]

Edit: Selecting vertices, and moving them across the map does not suffer from this problem.

 

Ah! At least we have a workaround for the time being. I was neurotically ctrl-G:ing all the time.

[Moonbo 827]

I'm pretty sure rotating brushes also causes them to snap off grid (or at least I've been seeing a lot more of this after upgrading Darkradiant).

[Grubber 7]

Hello, i came to this thread because of getting... frustrated by all my func_statics getting distorted/shifted while trying to build a map with all these great tools that the darkmod community has provided.

 

Now, what Sotha said is true and here is a little test i did to add some more info: make 2 brushes, place them at a 90 degrees angle together to create a corner both on the inside and outside. Select them both and move them around, the brushwork will stay fine as far as i can tell. Now make those brushes meet at a 45 angle to get a nice looking corner in radiant. Moving it is no problem, only if you rotate a lot, like 10 times on z-axis, it will get minor distortion. But now create a F_S and move it, i move my mouse very fast in circles when zoomed in and looking at where the brushes meet, the warping is very very scary...

[RPGista 600]

Hmmm... I've resumed work on my mission update - as long as I dont move inclined brushes around, I should be ok?