Wishlist For Darkradiant

[greebo]

Select a Tree > Menu Script > Select all models of same type > Hide (H)

[Tels]

Select a Tree > Menu Script > Select all models of same type > Hide (H)

 

Yes, that is a really nice tool. However, hiding is not the same as filtering, because there is (AFAIK) no "unhide", you can only unhide everything, or nothing. So as soon as you have hidden something you need later, and hit unhide, everything is back again, and then f.i. in forest, you would need multiple steps just to hide all the trees again (there are at least 5 or 6 different ones used).

 

What might work would be to sort the trees into layers, then you could toggle the layer on or off.

 

But having the ability to filter on model would still be a nice thing to have.

[Fidcal]

Selecting all trees and putting then in a layer is not a bad idea but it might conflict with a 'local area' layer. For instance, say you have a layer called garden which includes trees and you have another layer called field which includes other trees. It just about works but you have to remember if you want to work on garden and hide all layers except garden and trees it will also include the trees in the street area. I guess you could split the trees layer into two layers trees_garden and trees_field.

[Tels]

Selecting all trees and putting then in a layer is not a bad idea but it might conflict with a 'local area' layer. For instance, say you have a layer called garden which includes trees and you have another layer called field which includes other trees. It just about works but you have to remember if you want to work on garden and hide all layers except garden and trees it will also include the trees in the street area. I guess you could split the trees layer into two layers trees_garden and trees_field.

 

Yeah, but all that sorting into layers gets tedious, thats why I think having the additional "hide by model name" is a good addition.

 

Also, "select all same models" only lets you select things with the same model. The filtering allows regular expressions, so that you can hide all models that have "tree" in their name. That is much more powerful.

[Fidcal]

Did we ever have 'cameraToSelection'? I thought we did. That might be a useful shortcut. Currently in orthoview I select an object in the area I want, shift-MMB, turn the orthoview to another side and shift-MMB. If I don't select something first it might not be clear where to shift-MMB in a complex map. But a cameraToSelection would just need select then hotkey.

[Tels]

Is it possible to enter spawnarg descriptions so that an unlimited number of spawnarg with the same prefix is set as type?

 

For instance we have this:

 

"editor_model" "the model for this entity"
"editor_model_N" "additional models"

 

"editor_model" "the model for this entity"
"editor_model_<i>" "additional models"

 

But as far as I know none of these cause a spawnarg like "model_123" to be considered a model by the editor. This has the disadvantage that f.i. you are not prompted to select the model, making it much harder to select a model.

 

The same goes for other things like sounds, vectors, floats.

 

So is there already a working syntax for this? And if not, could it please be added?

[greebo]

Something like editor_model alone won't work anyway, the correct use would be

 

"editor_model model_lit" "Set to the model name the light should display when lit (usually a flame particle)."

 

This causes the EntityInspector to recognise the model_lit spawnarg as "model" type.

 

Something like you want is already possible via the .game file:

 

The model or particle system to be used when this entity is lit (i.e. for torches).

 

DarkRadiant treats that as regex. This is not performed for the editor_* spawnargs though, I guess that could be added.

[Tels]

Something like editor_model alone won't work anyway, the correct use would be

 

"editor_model model_lit" "Set to the model name the light should display when lit (usually a flame particle)."

 

This causes the EntityInspector to recognise the model_lit spawnarg as "model" type.

 

That was what I meant.

 

Something like you want is already possible via the .game file:

 

<property match="model_lit.*" category="Model" type="model">The model or particle system to be used when this entity is lit (i.e. for torches).</property>

 

DarkRadiant treats that as regex. This is not performed for the editor_* spawnargs though, I guess that could be added.

 

Er, yes, but that doesn't really solve the problem, because the ".game" file is totally sep. from our def files and is f.i. not updated when we update the def files. Plus, whenever I add "editor_model modelwhatever", how does the .game file play into this that "modelwhatever" is now recognized as a model (and not just a string)?

 

Case ein point are the "additional models" that can be set on a func_emitter. I have the relevant info in our def file, but how do I tell it DR? I think the game file is useless here, because if I update another code+def file next week, I'll run into the same problem again, that I'd somehow need to syncronise the .game file (where ever that is and however I access that).

 

Or did I misunderstand what the game file is for?

[Tels]

Finally manage to update to v1.5.x (thanx orbweaver and greebo!).

 

One thing that bugs me, tho, are the new buttons over the camera view that take a whole line of space, but are just 5 icons. I remember there was talk making this toolbar either hidable or moveable, but I can't seem to find the option, nor drag the toolbar to my main toolbar?

 

Here is a screenshot showing the space these 6 buttons waste, while there is a lot of space in the toolbars on the left or top:

 

[Tels]

Creating models from brushes/patches is very fast in DR for me: no need to learn a new interface, can see how it looks like in game in real-time, no need to match sizes etc, you can snap to grid and the models wll fit perfectly alongside some worldspawn.

 

However, I'd like to request a new, even more smaller grid size and a new zoom level at this point, as 0.125 is sometimes a bit too coarse, esp. if you want to match existing models.

[Serpentine]

I think 0.125 already runs into the 0.01 default vertexslop :/ (I think dmap uses the same value too)

 

It might be a bit better to replace 0.125 with 0.12 and then allow 0.06 via some option (before we have people starting out mapping using an even lower default )

[Tels]

I think 0.125 already runs into the 0.01 default vertexslop :/ (I think dmap uses the same value too)

 

It might be a bit better to replace 0.125 with 0.12 and then allow 0.06 via some option (before we have people starting out mapping using an even lower default )

 

I am not entire sure what you are getting at I do not want to use this for mapping, but for creating models.

[Serpentine]

Yah, and that wouldnt stop people trying to map with it... and no one is going to listen to a tiny warning telling them to avoid it.

 

Model vertices are also slopped at 0.01 (i.e those 0.00x's are ambiguous to doom, and I might guess cause the geometry issues working at low scales)

[Tels]

Yah, and that wouldnt stop people trying to map with it and no one is going to listen to a tiny warning telling them to avoid it.

 

Yeah, probably. But can I at least override it locally?

 

Model vertices are also slopped at 0.01 (i.e those 0.00x's are ambiguous to doom, and I might guess cause the geometry issues working at low scales)

 

Uhm, yeah, but some of our models (like our fences) have obviously vertices that are not snapped to a 0.125 grid. How come they do not cause issues then? *puzzled*

[OrbWeaver]

I remember there was talk making this toolbar either hidable or moveable, but I can't seem to find the option, nor drag the toolbar to my main toolbar?

 

Preferences -> Camera -> Show camera toolbar.

 

I do not want to use this for mapping, but for creating models.

 

I don't believe we should add features to DR that relate only to modelling rather than mapping, since it is intended to be a mapping tool. Unless this is needed for creating collision models, but in that case I doubt this much accuracy would be necessary (especially if D3 quantises the values as Serpentine suggests).

[Tels]

Preferences -> Camera -> Show camera toolbar.

 

Ah, ok, but that only hides it. Is it also possible to move the buttons to the main toolbar?

 

I don't believe we should add features to DR that relate only to modelling rather than mapping,

 

In my book mapping and modelling are so much intertwined (esp. with the new ASE exporter, and the ASE importer, and the in-game model-generator) that it will be hopeless to sep. the two. For instance, why would you consider building a "model" from brushes/patches (e.g. a window frame) "mapping", but building the same model in blender "modelling", when the outcome in the game is for all intents and purposes, the same?

 

Edit:

 

Or in other words, why should I leave DR when I can the task in it? Consider the aded objective editor, thetalk about a script editor, or a particle editor. In all cases you *could* use an external tool, but having the ability *right in the editor, tightly integrated with everything else* is a huge advantage.

 

I cannot stress the point of how much an advantage that is, basically all the plant and LOD models I created would not exist without DR and the ASE exporter.

since it is intended to be a mapping tool. Unless this is needed for creating collision models, but in that case I doubt this much accuracy would be necessary (especially if D3 quantises the values as Serpentine suggests).

 

While I can see your point of view, my point of view is from the other side - I want the feature and I *need* the feature (otherwise I need to invent a lot of (expensive for me) workarounds to achieve the same results.

 

While I agree that a grid of smaller than 0.125 might (probably) be bad for brushes/patches, it is good for models, or f.i. for cutting up wall sections along texture seems or whatever. I think the user *should* have the option to shoot himself into the foot, just because it allows the power users to achieve things that are otherwise quite complicated.

[Serpentine]

I did some testing, models actually don't have as much trouble at that side of the scale compared to brushes; Brushes having points that use/require 0.00x are what gives the "node without volume" message. Models however don't give any errors or render strangely (tho they can get bright edges), however they start to have very strange collisions, which is something quite interesting.

[OrbWeaver]

Ah, ok, but that only hides it. Is it also possible to move the buttons to the main toolbar?

 

Not without code changes. We don't have fully configurable toolbars at the moment, although some of the GUI manager infrastructure created by greebo might be a step on the path to this if somebody did want to implemented it.

 

In my book mapping and modelling are so much intertwined (esp. with the new ASE exporter, and the ASE importer, and the in-game model-generator) that it will be hopeless to sep. the two. For instance, why would you consider building a "model" from brushes/patches (e.g. a window frame) "mapping", but building the same model in blender "modelling", when the outcome in the game is for all intents and purposes, the same?

 

Modelling software like Blender provides a vast array of tools for creating complex models. Subdivision surfaces, constraints, deform tools, vertex and mesh editing, displacement maps, multi-res sculpturing, soft body simulation, the list goes on. Mapping tools by contrast have always provided a very rudimentary set of functionality: you can create blocky brushes and simple Bezier patches, and that's about it. Trying to bolt on extra features to make DR a proper modelling tool would be a fool's errand: it would distract developers from improving its functionality as a mapping tool, complexify and enlarge the codebase, and it would still be a poor modeller.

 

Or in other words, why should I leave DR when I can the task in it?

 

You could say the same about textures or sounds. Perhaps we should add some clunky image-editing functionality so mappers can create textures without having to learn GIMP or Photoshop, or an integrated sound editor in case mappers don't have another tool available?

 

Perhaps given infinite development resources, feature-creep wouldn't be a problem, and it would be possible to create a mapping tool that was also brilliant at creating all sorts of other assets. However, in reality the choice is between a tool that is good at one thing, or not very good at a lot of things. Having been involved with a commercial project that was an abject failure and cost several people their jobs because its remit was to "Do everything! Better than any one existing tool!" I have a strong preference for the former.

 

While I can see your point of view, my point of view is from the other side - I want the feature and I *need* the feature (otherwise I need to invent a lot of (expensive for me) workarounds to achieve the same results.

 

But you already have the features, in the form of freely-available modelling tools like Blender. It may seem more convenient not to have to learn a new tool, but in the long run you will be much better off using a tool that is right for the job rather than using a screwdriver as a hammer which can be made to "kind of work" but will always have limitations and problems.

 

While I agree that a grid of smaller than 0.125 might (probably) be bad for brushes/patches, it is good for models, or f.i. for cutting up wall sections along texture seems or whatever. I think the user *should* have the option to shoot himself into the foot, just because it allows the power users to achieve things that are otherwise quite complicated.

 

Ah, well if there are legitimate mapping reasons to remove the grid limitations, that's a whole different discussion. In fact I don't have any strong feelings on this particular feature (I did not even know the grid couldn't be disabled), I'm just opposed to feature creep in general.

[Tels]

Not without code changes. We don't have fully configurable toolbars at the moment, although some of the GUI manager infrastructure created by greebo might be a step on the path to this if somebody did want to implemented it.

 

It is not a big deal, but it would certainly be nice if someday the toolbars could be re-arranged.

 

(Edit: and I certainly understand that this is not a high priority at all and a lot of work)

 

Modelling software like Blender provides a vast array of tools for creating complex models. Subdivision surfaces, constraints, deform tools, vertex and mesh editing, displacement maps, multi-res sculpturing, soft body simulation, the list goes on. Mapping tools by contrast have always provided a very rudimentary set of functionality: you can create blocky brushes and simple Bezier patches, and that's about it. Trying to bolt on extra features to make DR a proper modelling tool would be a fool's errand: it would distract developers from improving its functionality as a mapping tool, complexify and enlarge the codebase, and it would still be a poor modeller.

 

Yeah, but one could also argue the othr way: Not only is Blender a *heavy* investment (step learning curve), it also creates suboptimal results until you reach a certain level. Plus provides a lot of functionality that you don't need (e.g. animation, or things that do not work in D3 anyway). As example we have/had a lot of models that have gaps (because units in Blender and units in DR are totally sep, there doesn't seem to be a grid in blender by default etc). Then there is the entire exporting/importing/re-exporting thing, the mismatches of textures and materials etc etc.

 

Sometimes it certainly looks like Blender creates more problems it solves, esp. if all you want to do is to create a new shovel (and not say "statue of aphrodite and paris kissing" .

 

You are right about *very* advanced models like statues, but I am talking about simple things like fences, a stair step, a window or a new door handle. These simple models should be simple to construct.

 

You could say the same about textures or sounds. Perhaps we should add some clunky image-editing functionality so mappers can create textures without having to learn GIMP or Photoshop, or an integrated sound editor in case mappers don't have another tool available?

 

No, textures/sounds are (IMO) assets. Models are not seperate assets, they are an integral part of the map like brushes or patches. As in "the renderer doesn't actually care whether it renders a func_static or a model" and the engine also makes very very little distinction between these two. A model in d3 is just a collection of tris, just like a func_static.

 

Perhaps given infinite development resources, feature-creep wouldn't be a problem, and it would be possible to create a mapping tool that was also brilliant at creating all sorts of other assets. However, in reality the choice is between a tool that is good at one thing, or not very good at a lot of things. Having been involved with a commercial project that was an abject failure and cost several people their jobs because its remit was to "Do everything! Better than any one existing tool!" I have a strong preference for the former.

 

But you already have the features, in the form of freely-available modelling tools like Blender. It may seem more convenient not to have to learn a new tool, but in the long run you will be much better off using a tool that is right for the job rather than using a screwdriver as a hammer which can be made to "kind of work" but will always have limitations and problems.

 

Apart from the fact that I ask about a simple "also allow grid U in addition to Z, Y, X, W, V" plus "allow one more zoom step" (which is IMO not a feature, more like a minor tweak), I just disagree that DR is the wrong tool for building "simple models". Otherwise, you would just ask every mapper out there to construct every window, doorframe etc in Blender. Which might make sense in the sense of "oh it will be easier (once you spent a long time learning blender) and look better", but it doesn't make sense in the context of "the mapper has limited resources".

 

It is almost like asking the mapper to write a 2 line script instead of setting 10 spawnargs. Sure, a script is the proper tool for the job, but it is still way beyond most mappers, esp. if they already have 9 spawnargs and just ask for the tenth to be added. In this context to ask them "oh just learn programming" will simply not work.

 

(I think this discussion is getting derailed by me

 

Anyway:

 

Ah, well if there are legitimate mapping reasons to remove the grid limitations, that's a whole different discussion. In fact I don't have any strong feelings on this particular feature (I did not even know the grid couldn't be disabled), I'm just opposed to feature creep in general.

 

I am there with you, feature creep is rarely a good thing. But IMO "mapping" is official part of the official mission statement and goal chart of DR, and building things with fine details is an integral part of mapping. (To top off the buzzword bingo sheet

 

As for disabling the grid, I don't think this is a good idea. Snap-to-grid is very important.

 

But that reminds me, it is already possible to build things "off-grid" by f.i. rotating them. Or resizing them. So you can build your model as oversized version, then simply scale it down beyond 0.125 grid size

 

You just have the creating steps a tad more complicated, and you still can't zoom into the final model close enough.

 

So I am not entirely sure why NOT allow such a small grid size (with a red warning "you have just enabled a very fine grid, use this not for creating world spawn" or such) and why NOT allow a clsoer zoom level in the orthoviews.

[Fidcal]

May I suggest that when one caps an inverted cylinder that it produce the caps for two inverted endcaps? Is that possible?

[Bikerdude]

May I suggest that when one caps an inverted cylinder that it produce the caps for two inverted endcaps? Is that possible?

er I though it did already fids..?

• create cylinder
  
• press ctrl-i to invert
  
• press ctrl-c to create end caps
  
• bobs yer uncle..
  

is that what you mean..?

[Baddcog]

quote Tels: As example we have/had a lot of models that have gaps (because units in Blender and units in DR are totally sep, there doesn't seem to be a grid in blender by default etc). Then there is the entire exporting/importing/re-exporting thing, the mismatches of textures and materials etc etc

I really doubt gaps are because of blender/dr scale or grid. Model verts don't move because of Doom compiling OR scale/grid issues.

I know some of the oldest models have some gaps, (big generator is one I remember, but that was lwo I believe, don't know who/when it was modelled) but I don't know of any more recent ones.

 

I can set my Max scale to the exact scale of DR and don't see why Blender would be different. Most likely it's 'sloppy modelling'.

One issue with modelling for Doom3 is that smoothing groups can't be set, the edges just need split.

 

 

This means breaking the verts apart in model prog, then exporting (and hoping you don't accidentally budge part of a model, etc...). In other games you can set smoothing groups on individual faces and leave verts welded. Essentially the verts get split on conversion, but that gives less chance of error from the modellers to create a gap.

 

Models aren't generally snapped at all, that is one thing that is so nice about modelling details, you don't need a grid. I rarely snap, only when doing something like the doors that I want to be precise to the DR grid. Or (in other games) tiling terrain pieces that need to align to grid exactly so the edges match (ie: floor tiles, street tiles).

-----------

Other reasons to use a modelling program.

 

Patches can make nice rounded wood beams, stairs, etc.. But using patches generally gives you a grid of tris that is overkill. Works OK because the engine can handle a lot of tris, but generally you can use half as many tris in a modelling program and achieve the same look.

 

You also have much better control over smoothing groups, baking, baking normals, texture application (DR's tex tool is nice but still not as good as a modelling program), shapes can be more organic due to the fact the verts don't need to snap to grid...

 

Most model exporters were never intended for a modelling package replacement as much as a 'scale exporter'. I think the entire idea was just for and quick scale/position reference to use in a model package to save the back and forth exporting to get it just right.

It's great to be able to turn DR work into models, but doing anything very specific or detailed would just be a nightmare imo compared to modelling it.

[Springheel]

I know some of the oldest models have some gaps, (big generator is one I remember, but that was lwo I believe, don't know who/when it was modelled

 

I fixed the generator and several others over the years. If you find ones that still have gaps, let me know.

 

In other games you can set smoothing groups on individual faces and leave verts welded

 

I can still do this in LW.

[Fidcal]

er I though it did already fids..?

• create cylinder
  
• press ctrl-i to invert
  
• press ctrl-c to create end caps
  
• bobs yer uncle..
  

is that what you mean..?

No. ctrl-c is standard Windows copy. It has no effect here. If you have customised that hot key what keyword did you use?

[Fidcal]

Another idea I'd like to see is ortho zoom to point. Currently the mousewheel zooms ortho but the cursor is not taken into account. Effectively the mousewheel just zooms the whole panel in and out.

 

But typically in use you want to zoom *to* something. Suppose you are in top view above a city and want to work on a courtyard at north east. Currently you would drag that roughly to the centre, zoom, repeat, repeat.

 

An alternative is to use say Shift+Mousewheel to zoom to the cursor position. I see two ways to do that:

 

1. 
    
   
2. The cursor remains where it is relative to the ortho panel/monitor screen and mousewheel stores that cursor xyz position, zooms, then redraws with that xyz pos back under the cursor.
   
3. Another way is to centre ortho around the cursor then zoom. This effectively moves the cursor to the centre on the first zoom. I'm not sure if there is any problem with that.