Jump to content
The Dark Mod Forums

Dark Radiant talk


STiFU

Recommended Posts

I didn't want to spam the DR bugtracker, so I thought I'd open this topic.

 

I actually posted some of these things in the bugtracker already, but I wanted to discuss it a little. In GTK Radiant grouped brushes (func_group or func_static) were treated differently. First of all if you shift-clicked a brush you really only had the brush selected you clicked and if you clicked "expand selection to whole entities" (or used the keyboard shortcut ctrl+alt+e), you had the whole group selected. In DR you shift-click a brush and have the whole group selected directly and have to toggle through the childbrushes by hiting tab or selecting them in the entitylist. This is a lot slower than the original method and it also makes "expand selection to whole entities" useless, since it only works on the worldspawn at the moment.

 

Also, is there a way to group grouped brushes or entities? This could create an interesting and usefull tree structure for the brushwork (and maybe entities), eventually ending up in the worldspawn. Let me explain what I mean with an example:

You build a support-beam structure out of brushes and group the brushes together. You use that brushgroup a couple of times in your map, combined with further beamstructures and group those together again, in order to be able to easily change the texture or alter its texturescale etc later on. In this context the "expand selection to whole entities"-function should be redesigned to "Select whole parent". You select a part of your supportbeam, hit ctrl+alt+e and have the whole supportbeam selected. Hiting ctrl+alt+e again selects the rest of the beam-brushwork. This would enhance workflow a lot and is a simple and intuitive way to save selections I think!! :)

 

I hope my criticism is esteemed constructive and not destructive. You've achieved some nice things so far with DR, but I think it could become even better... :wub:

Link to comment
Share on other sites

I understand your suggestion, and I think it has its advantages over the current solution. However, if I'm not remembering incorrectly, the current solution was actually requested by mappers, so I'm not sure if people are all that happy if brushes belonging to func_statics are treated as if they were unconnected (selection-wise).

 

This should probably be discussed with the other Beta Mappers or made an option.

Link to comment
Share on other sites

Yes long ago it was requested that selecting any part of a group object would select the whole, then the user can step through the children. The rationale was that once such an object is created, the mapper will want to work with that object as a whole the vast majority of the time, instead of the parts, so it was one of convenience. That said though, I can see wanting the opposite behavior as well. Example: you have one of Dram's banister/railing func_statics, but you just want to texture one banister differently. As it currently is, you'd select it, which would select the entire group, and then tab to the individual part. But there are a lot of parts (perhaps hundreds). That could be a lot of tabbing. In that case, the select-child-first, expand-to-whole-entity (if it works) would be best. Maybe an option would be a good way to go.

 

Ways to super-group items (brushes, unrelated ents, or even brushes and ents) is still up in the air, AFAIK.

Link to comment
Share on other sites

Yes long ago it was requested that selecting any part of a group object would select the whole, then the user can step through the children. The rationale was that once such an object is created, the mapper will want to work with that object as a whole the vast majority of the time, instead of the parts, so it was one of convenience. That said though, I can see wanting the opposite behavior as well. Example: you have one of Dram's banister/railing func_statics, but you just want to texture one banister differently. As it currently is, you'd select it, which would select the entire group, and then tab to the individual part. But there are a lot of parts (perhaps hundreds). That could be a lot of tabbing. In that case, the select-child-first, expand-to-whole-entity (if it works) would be best. Maybe an option would be a good way to go.

 

Ways to super-group items (brushes, unrelated ents, or even brushes and ents) is still up in the air, AFAIK.

 

What about "CTRL-SHIFT click" selecting only one part of the group?

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Or Ctrl+LMB?

I think it's not reserved yet either and extra convenient. I hope you can implement super-grouping. After all, treestructures are always powerfull. :) Complex objects like Dram's, which you were talking about, could then be subdivided into groups, for better customizing and a better overview. DR would alomst be like a normal 3D-app then.

Link to comment
Share on other sites

Or Ctrl+LMB?

So far everything that's toggling a selection is involving the SHIFT key, so this would break the consistency.

 

I hope you can implement super-grouping. After all, treestructures are always powerfull. :) Complex objects like Dram's, which you were talking about, could then be subdivided into groups, for better customizing and a better overview. DR would alomst be like a normal 3D-app then.

The scenegraph refactor is on our roadmap to DarkRadiant 0.9.6, together with the Objectives Editor. This will require a large (if not huge) amount of work, and we included layering and grouping into the design. Work on it hasn't started yet, so don't expect it too soon - the Thief's Den pre-beta release is currently requiring our full attention.

Link to comment
Share on other sites

What about [...]+LMB selecting only one part of the group?

 

After reading SneaksieDave, I'm tending in his direction, which would flip this idea on its head. Default LMB clicking a part should select just that part, and [whatever]+LMB should select the whole group ("whatever" being whichever key is free and works). It seems human nature that when dealing with just the part you want to fix, you want to first just grab it as a reflex. But to deal with something more abstract you're more ready to take a special action.

 

For what it's worth, this is how dromed currently handles multibrushes. LMB a part to select a single brush, shift+LMB selects the multibrush (group). So there's precedence. And it feels right, too. But granted I haven't built in DR yet; it's just my intuition.

Edited by demagogue

What do you see when you turn out the light? I can't tell you but I know that it's mine.

Link to comment
Share on other sites

and we included layering and grouping into the design.

NICE! :) One question about that though, will you limit the stages of grouping (depth of the tree) or will it rather be completely dynamic?

 

Of course, you want to concentrate on the demo first and we want you to do so too, since everyone just wants to play in the end! :) But I am absolutely of demagogue's oppinion, it's still not that important which way we go though. I'd just prefer to press a single key instead of two, to select a brush, that's why I suggested Ctrl+LMB and I thought it was very convenient/effective because you'd only use two buttons and one combination of the two for the different Selecttypes. With your suggestion you'd have the opposite: one button and two combinations of different buttons. But I am really unneccessarily picky here. I'll use it no matter how you guys decide... ;)

Edited by STiFU
Link to comment
Share on other sites

Renderbump spits out shit

I tried renderbump now for the normal generation from an high res to a lowres mesh and it returns shit. Take a look:

awkwardnormalfm9.th.jpg

As you can see on the normal, faces that are supposed to be straight (they are straight on the highres mesh as well), are not straight, which looks really awkward ingame when the light comes from an unfavorable direction:

ingamescreenshotym9.th.jpgwindowuf1.th.jpg

 

Do you have some ideas how to fix this, or is there perhaps a better way to bake normals? (I'm using 3ds max, but I guess for the normal baking I could just use any tool) Maybe it has something to do with the smoothing groups? Very unlikely I think...

Edited by STiFU
Link to comment
Share on other sites

Do you have some ideas how to fix this, or is there perhaps a better way to bake normals?

 

This is a common problem. You need to make sure that the low-poly mesh is completely smoothed (no splits), and use face splitting on the high-poly model to introduce non-smoothed areas into the normal map.

Link to comment
Share on other sites

Ok, sorry. I started this thread with the intention to initialize a spot for q&a about DR editing and DR related stuff though. ;) Gonna try xNormal now, but what do you mean by "angua"? Is that another normalbakery? :)

Link to comment
Share on other sites

but what do you mean by "angua"? Is that another normalbakery? :)

 

Never, ever call a woman "normalbakery". You might end up with a cake mold embedded in your head :)

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Ok, then say sorry to Angua aaaand back 2 topic... ;) Neither did work aparently. I deleted all smoothgroups on the highres mesh, which creates this faceted look (I guess this is what you meant, isn't it?) and I put all polys of the lowres mesh into one smoothgroup. Didn't change the way, the normalmap rendered at all aparently... :(

 

I also got some problems with xNormals. Seems to be very buggy. At first it wouldn't load up ASE-files, so I exported as OBJ. Then it seemed to calculate something finally, but after 15 minutes I stoped it, since it originally took 10 minutes to render in doom 3. Then I loaded up one of those example cfgs, reverted to defaults again, after some time and all the sudden it rendered. But now there seems to be something wrong with the uvlayout, because it only renders very little of the whole mesh and I think way too fast, because the rendering process takes like 7 secs now, no matter how I export my meshes. Awkward...

 

Edit: After some internet research I found that even though renderbump is rendering the same awkward gradients it can still look different if you have changed smoothing or something else on the mesh and after testing I noticed that it works better now... :) Still not perfect though, as you can see at the upper stoneedges:

clipboard01lg9.th.jpg

 

So thanks guys. Here is a really good explanation of this tangent smoothing by the way.

Edited by STiFU
Link to comment
Share on other sites

So many male jokes in this thread. :rolleyes: I feel sorry for Angua sometimes...

My games | Public Service Announcement: TDM is not set in the Thief universe. The city in which it takes place is not the City from Thief. The player character is not called Garrett. Any person who contradicts these facts will be subjected to disapproving stares.
Link to comment
Share on other sites

Didn't change the way, the normalmap rendered at all aparently...

 

No, it doesn't. What it does is ensure that the gradients in the normal map are cancelled out by the smoothing on the low-poly model, which is why they are appearing in the first place: when renderbumping Doom 3 assumes that a low-poly model is completely smoothed, no matter which smoothgroups are applied.

 

I think you can also prevent the gradients altogether by separating out the faces on the UV layout (so that they don't share vertices), but I have never tried this.

Link to comment
Share on other sites

Ok, sorry. I started this thread with the intention to initialize a spot for q&a about DR editing and DR related stuff though. ;) Gonna try xNormal now, but what do you mean by "angua"? Is that another normalbakery? :)

That's me. I'm not a normal bakery, but I am good at normal mapping. :laugh:

 

So many male jokes in this thread. :rolleyes: I feel sorry for Angua sometimes...

Heh, no problem :P

 

I'm using xNormal version 3.9.4, I remember having problems with newer versions. You should really be able to use ase files.

Make sure your low poly model has a uv layout that doesn't overlap (the one you're using looks good), your high poly model doesn't need one. If a part of your normal map simply isn't rendered, try increasing the trace length. I've often had parts of the model where the blue was too low (maybe the trace went into the wrong direction). In those cases you have to invert or simply increase the blue.

 

On a sidenote: That ornamental texture below the window is nice, is that yours?

Link to comment
Share on other sites

Yes, thanks and hi angua. :) It's just a phototexture I made tiling1d and crazybumped it, with very little specularity added. Nothing special. I was thinking about applying for beta mapper status maybe, so I made a couple of textures (about 25) and now I am producing some smeshes, to make a little test map and if I like what is coming out of it, I am going to post it here. Not sure yet though whether I'll have the time for producing a whole map, so at the moment, I am just producing content, which I am of course going to donate (if you want that is)... :)

 

I actually didn't make sure the uv layout didn't overlap so far though. What came out of it are the final results of renderbump, i did nothing with that layout. But as I tried to seperate the faces on the uv-layout like suggested in the link, I also made sure that nothing's overlapping of course...

 

When I used xNormal I noticed that way too many traces failed (~3500). I didn't know how the technique used to render the normalmaps, but by now I do, so I increased the size of the highres mesh, so that the traces are always hiting something. Later I noticed that I didn't have to do that, because there is a toggleswitch, that enables tracing in both directions. I am going to try to increase the tracedistance now... Well, there is actually no option to do so in my version (3.12.0.409...), which is supposed to be the latest stable release. I'll just stick to renderbump. It's not that bad in the end, since I don't have worry in which direction I workout the details and stuff like that.

 

By the way, in the link I posted it was said, that doom 3 can render unsmoothed tangents. Adding the parameter "unsmoothed tangents" to the material file like suggested here doesn't work though. Anyone got some information on that? The result of it looks disgusting on the screens, but I'd like to see the difference in my example and maybe it gives even better results, who knows? =)

Edited by STiFU
Link to comment
Share on other sites

  • 2 weeks later...

Hey one question about patches. It's said in the wiki that they don't seal against the void, so I guess I have to use solid textures behind every patch instead of caulk, for the visportals to work, right?

 

That unsmoothedtangents thing is written without a space between the two words, so it was just sort of a typo that made it fail. I didn't test it any further now though, 'cause I got it workin...

 

Also this thread should maybe be moved into the darkmod editor's guild, as well as that noob texturing/modelling thread...

Edited by STiFU
Link to comment
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.

  • Recent Status Updates

    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 0 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
    • nbohr1more

      Please vote in the 15th Anniversary Contest Theme Poll
       
      · 0 replies
×
×
  • Create New...