Jump to content
The Dark Mod Forums
Sign in to follow this  
greebo

Testers needed: DarkRadiant + wxWidgets

Recommended Posts

I've had the invisible brush and path node issue too when I tried pre5 last night. One of my tests maps has only 7 brushes and 3 entities (it's an isolated dmap bug, that's why), and only lights show up. They are there, because I can use the find brush dialog to select them and show their extents, but nothing shows on screen. Freshly created brushes do show in the map. And another test map for lod AI shows about half its brushes plus arrows for the path nodes but not the nodes. The only console errors were concerning _white and _fog textures being unresolveable. I'll upload them to tracker I'd it helps.

Share this post


Link to post
Share on other sites

Let's try, I just want to attempt to reproduce that behaviour. If that doesn't work on my end, I need to figure it out using your console output or other means.

 

Map, materials, base textures (it has ambient light, and AAS somehow is incompatible with Doom 3; you'd need to dmap it before trying to load in TDM): https://drive.google.com/file/d/0BwE6dxM0O2PsM3dZUHdIYV9ycjg/edit?usp=sharing

 

Console output: http://pastebin.com/nDCk7nXV

Share this post


Link to post
Share on other sites

Thank you, I get the same picture as you, all the brushes are invisible and the path_corners too.

Share this post


Link to post
Share on other sites

Yes, the changes I made to Frustum::testIntersection are causing the problem. I need to get some paper and pencil and re-do the calculations, I reckon.

Share this post


Link to post
Share on other sites

Ok, a new build is up (pre6), get it in the first post. It was only partially due to my changes, the other part was due to pure insanity in DR's view/math code that is silently assuming that the value in Plane3::dist() is actually d as in the plane equation ax+by+cz+d=0. I changed the AABB intersection code when working on the projected light stuff, using the correct Plane3 members, and that's what broke the View culling code. It's quite possible that I'm going to have more fun in the future with that legacy crap.

 

The full solution would be that either DarkRadiant switches its Plane3 class to store a,b,c,d (which is more common and better in some ways) or all the "wrong" or at least "old" code is migrated to a,b,c,dist at some point.

Share this post


Link to post
Share on other sites

Thought I would try this version out, but found a bugs, one of which is a show stopper. I nuked my old 1.8.x prefs before installing this version.

 

Bugs:

  • Layers popup - the text box text isnt being re-centered as you resize the window (see attached)
  • Preferences window - from the camera settings down the r/h pane is fubard (see attached)
  • All models missing in ortho - there is no filter, in opening a model from the viewer just show an axis in the ortho window (see attached)
  • browsing for map files - this is much slow than compared to 1.8.x, there is a 0.5-1s delay after each click.

Feedback:

  • Its still slow to open to desktop than 1.8.0 and you get two pop-ups when loading a map.
  • The above pop-ups cause a weird overdraw effect when dragged around when loading a map.
  • Scrolling around in cammera view is much slower than 1.8.x (1.8.0 is still the fastest of the bunch with far-plan clip turned off)

post-496-0-05047200-1408285397.jpg

post-496-0-59959800-1408285454_thumb.jpg

post-496-0-35481400-1408285530_thumb.jpg

Share this post


Link to post
Share on other sites

I can confirm the missing models, this is probably another issue related to the changes in the math code. I'll look into that.

Share this post


Link to post
Share on other sites
Layers popup - the text box text isnt being re-centered as you resize the window (see attached)

What do you mean exactly? Are you referring to the fact that the window can be resized to a size narrower than necessary to draw all the controls?

 

Preferences window - from the camera settings down the r/h pane is fubard (see attached)

Hm, I can't reproduce that one. I tried both debug and release builds, it works every time. Does anybody else get that?

 

All models missing in ortho - there is no filter, in opening a model from the viewer just show an axis in the ortho window (see attached)

I could fix that one.

 

browsing for map files - this is much slow than compared to 1.8.x, there is a 0.5-1s delay after each click.

Can't reproduce that one at all. In fact the FileChooser is a native Windows dialog now - maybe some on-access scanner is interfering with your .map files?

 

Its still slow to open to desktop than 1.8.0 and you get two pop-ups when loading a map.

I think I don't understand. What do you mean by "open to desktop" and "two popups"?

 

The above pop-ups cause a weird overdraw effect when dragged around when loading a map.

You mean the "Loading map" progress dialog? That one is blocking any 3D drawing while loading (for obvious reasons). For me it doesn't cause any effect when dragging that window around during map load.

 

Scrolling around in cammera view is much slower than 1.8.x (1.8.0 is still the fastest of the bunch with far-plan clip turned off)

I ran a short profile session, and it seems that the PatchRenderables are spending about 8% of their time for vector maintenance, as the VBO structures are rebuilt on every render() call it seems. I haven't investigated further, and I need to talk to OrbWeaver as well, quite possible that he had his reasons to move the update code to the render() call. The 8% are relative to to all patches in the map, which make up about 40% of the overall rendering time in my test scenario, I'm not sure if that little gives such a noticeable effect, but it should be optimised nonetheless.

Share this post


Link to post
Share on other sites

Btw, new build is up in a minute (pre7), fixes the missing models.

Share this post


Link to post
Share on other sites

One thing I just noticed, that happens even in 1.8.1 (or maybe because 2.0.0pre changed defaults I had for 1.8.1 simply because it uses same Roaming profile) - Esc doesn't deselect selected elements in the scene, and even if I use Clear Selection from the menu, it doesn't work on first selected element. I need to select something else, and then Clear Selection would work.

 

Everything seems to be drawing, except now connections between linked/targeted elements don't render:

 

1.8.1: http://i.imgur.com/8HwvF3j.png

2.0.0pre7: http://i.imgur.com/MtcqB72.png

 

Also somehow holsters textures on my NPCs don't show :/ (they are rendered in 1.8.1)

Share this post


Link to post
Share on other sites

The ESC being unbound is one thing that happens when switching back to 1.8.x with a profile that has been saved in the recent 2.0.x versions. Moving forward to 2.0.x should recognise the ESC binding, but the older 1.8.x doesn't recognise the newer key code.

 

I'll check out the missing target lines. Do I have the defs for the missing holster textures in the map package you sent me? Otherwise, please send me an example for me to work on, I'll try to investigate.

Share this post


Link to post
Share on other sites

The ESC being unbound is one thing that happens when switching back to 1.8.x with a profile that has been saved in the recent 2.0.x versions. Moving forward to 2.0.x should recognise the ESC binding, but the older 1.8.x doesn't recognise the newer key code.

 

I'll check out the missing target lines. Do I have the defs for the missing holster textures in the map package you sent me? Otherwise, please send me an example for me to work on, I'll try to investigate.

 

There is nothing special about def:

 

 

entityDef npc_usf_bold_unarmed_patrolman {
"inherit" "npc_usf_base_character"
"skin" "skins/union_patrolman/pistol_holstered"
"def_head" "head_union_patrolman_default"
"head_joint" "chest"  
"anim" "idle"
"mass" "200"
}

 

and skin:

 

skin skins/union_patrolman/pistol_holstered {
models/enemies/base_torso_short_sleeve models/enemies/base_torso_short_sleeve
models/enemies/base_legs models/enemies/base_legs
models/enemies/base_boots_kneepads models/enemies/base_boots_kneepads
models/sfx/muzzleflash_fireflare2 textures/common/nodraw
models/sfx/muzzleflash_firebeam2 models/sfx/muzzleflash_firebeam2
models/sfx/muzzleflash_fireball2 models/sfx/muzzleflash_fireball2
models/enemy_weapons/plasma_pistol textures/common/nodraw
models/ammo/plasma_cartridge_flintlock textures/common/nodraw
models/enemy_weapons/plasma_pistol_holstered models/enemy_weapons/plasma_pistol
models/ammo/plasma_cartridge_flintlock_holstered models/ammo/plasma_cartridge_flintlock
}

Share this post


Link to post
Share on other sites

Ok, and the textures are missing in the Camera View? These are custom shaders or Doom3-based ones?

Share this post


Link to post
Share on other sites

Ok, and the textures are missing in the Camera View? These are custom shaders or Doom3-based ones?

 

Missing from CAM view (as seen on screenshots). Materials(!) are the same as Doom 3, with custom shader stage. However, body/head/etc. per characters all have the same custom shader stage, and yet body texture is showing fine, but holster texture isn't being shown. I'll check if the material has qe4_editorimage set, but it shouldn't make any difference between 1.8.1 and 2.0.0.

Share this post


Link to post
Share on other sites

Missing from CAM view (as seen on screenshots). Materials(!) are the same as Doom 3, with custom shader stage. However, body/head/etc. per characters all have the same custom shader stage, and yet body texture is showing fine, but holster texture isn't being shown. I'll check if the material has qe4_editorimage set, but it shouldn't make any difference between 1.8.1 and 2.0.0.

I can't see that effect in the package you gave me, there aren't any AI in the view so I can't compare between 1.8.1 and 2.0.0, let alone debug it. Can you provide me with a small package that shows the effect? A single AI without any brushes in the map is more than enough.

 

Btw, I fixed the problem with the target lines.

Share this post


Link to post
Share on other sites

Just a question out of curiousity: Is it possible to integrate L18n! for readables in DR? Or is this already done? :)

It's definitely not done. I haven't thought about it yet, so I can't say how much work it would be.

Share this post


Link to post
Share on other sites
I can't see that effect in the package you gave me, there aren't any AI in the view so I can't compare between 1.8.1 and 2.0.0, let alone debug it. Can you provide me with a small package that shows the effect? A single AI without any brushes in the map is more than enough. Btw, I fixed the problem with the target lines.

 

As I was packing assets for you, I was looking for pistol's material. I found it and as I suspected, it didn't have qe4_editorimage set. After I added it, holstered pistol shows textures in 2.0.0

 

I wonder if was intended change (technically that's what qe4_editorimage is there fore - to show texture in the Editor) from 1.8.1, or a bug where if qe4_editorimage, DR should use "diffusemap" image or image map from "blend diffusemap" ?

 

If you still need a test case, I can make a basic cube.

Share this post


Link to post
Share on other sites

Hm, I used some of your material defs (textures/grid1024blue and textures/grid1024) which have a blend diffusemap and a diffusemap stage, respectively. I removed the qer_editorimage keyword and they both showed up in DarkRadiant, so I can't quite reproduce it here. Can you show me the material with the missing qer_editorimage that fails to show in DR?

Share this post


Link to post
Share on other sites

I'm a bit late, but I confirm that my brush and path node visibility problems got fixed too in update 6 or 7.

Share this post


Link to post
Share on other sites

Thanks for the confirmation.

 

Bikerdude will probably like this: I could improve the frame processing time of a large production map from 230ms to 170ms by updating the patch VBOs only when the tesselation actually changed. However, I'm committing this change to a post-2.0 branch, since I'm hesitant to load more changes onto the codebase in this phase of testing. My projected light changes proved once more that even small things can have brutal side effects, so I'm holding this back for the release after 2.0.0.

Share this post


Link to post
Share on other sites
I could improve the frame processing time of a large production map from 230ms to 170ms by updating the patch VBOs only when the tesselation actually changed.

 

I started on some changes locally that would do this but it looks like you beat me to it (unsurprisingly). I'm glad to see that it actually makes a difference.

Share this post


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.

Sign in to follow this  

×
×
  • Create New...