[Is development of DR pretty much dead ?]

Tons of applications are having trouble with Gamma on Windows 10...

 

See the current Sneaky Upgrade thread at TTLG where Snobel has been fighting that...

 

I am still on Win7. Just wondering if it's fixable in DR, so that eventually it just works out of the box.

[Is development of DR pretty much dead ?]

It doesn't help that the latest release version has some new bugs on certain systems, but like Melan said, it's complete and earlier versions are available for those who need them. It can also be extended by python scripts.

 

The one thing I'd like to fix if ever I get my head round the DR code would be rotating prefabs that are made of several objects that start off on different rotations. They end up moving in crazy directions.

 

It would be nice to make it run on Windows 10 properly (I saw something about DR messing up gamma).

 

Yeah, it would be nice to fix the rotations (allow all selected objects to be rotated around its axis; or around median, or around last selected object).

 

It would be also nice to allow grouping of func_statics and brushes using func_group! Or something internal to DR, like layers are implemented. Very useful for modular level design.

[Is development of DR pretty much dead ?]

So, I haven't seen any movement on Github/Gitlab nor any traces of DR's devs on this forum lately.

 

Is it safe to say DR development is in stasis (or worse) ?

[Decals with normal maps ?]

That's something I was wondering about too (a sample material)

 

I assume it would be regular material with alphaTest. Not really a decal as you know them.

[Decals with normal maps ?]

Can decals have normal/spec maps ? (decals as in patches manually placed on the level)

 

Thanks.

[Scaling func_statics in DR - how to implement ?]

Fixed it!

 

http://pastebin.com/YzVvPuaY

 

q3 bool doesn't get updated I think. Once I checked it very first time to be true, no matter what I do to it now, modelscale always get added (which isn't a bad thing since Doom 3 games ignore that spawnarg anyway)

[Scaling func_statics in DR - how to implement ?]

Alright, tested. It no longer created "modelscale" spawn arg, and even if I add it manually, it doesn't update it. Immediately after I press Ok, I get the following error (model is being scaled though):

Error while executing file: commands\scale.py: 
Traceback (most recent call last):
  File "G:/games/DarkRadiant203pre5/scripts/commands\scale.py", line 79, in <module>
    execute()
  File "G:/games/DarkRadiant203pre5/scripts/commands\scale.py", line 75, in execute
    selectedEntity.setKeyValue('modelscale', scale)
Boost.Python.ArgumentError: Python argument types in
    EntityNode.setKeyValue(EntityNode, str, float)
did not match C++ signature:
    setKeyValue(class script::ScriptEntityNode {lvalue}, class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >, class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >)

[Scaling func_statics in DR - how to implement ?]

Fixed.

 

Seems to be working fine, except modelscale spawnarg doesn't get updated. It's always "modelscale" "1"

[Scaling func_statics in DR - how to implement ?]

Thanks! I'll test it after work.

 

I did some tests on the subject of kitbashing and draw calls. If func_statics are inlined, there will be same number of draw calls as if there is only one func_static in the view. Unfortunately if entities are not inlined, there is no batching happens. That's another thing on our to-do list (or rather it needs to be investigated and determined whether it worth the effort to batch static models in the run time; it would definitely require running batching on a separate thread to maintain performance)

[Scaling func_statics in DR - how to implement ?]

Thanks again rich!

 

I thought it's a bit more advanced (the API that is). Widget is the goal, but it'll take time for us to implement.

 

If I hit Cancel without entering any value, I get the following error:

Error while executing file: commands\scale.py: 
Traceback (most recent call last):
  File "G:/games/DarkRadiant203pre5/scripts/commands\scale.py", line 74, in <module>
    execute()
  File "G:/games/DarkRadiant203pre5/scripts/commands\scale.py", line 59, in execute
    if scale > 0:
UnboundLocalError: local variable 'scale' referenced before assignment

Also, how to I turn on a checkbox by default? (so it's always on)

 

Thanks beforehand!

[Scaling func_statics in DR - how to implement ?]

Thanks rich! Crazy awesome stuff!

 

I tested it and I got a few suggestions/questions about workflow.

 

When scale is set to 0, it should do nothing. Currently model disappears.

 

Is it possible to keep dialog always visible and always on top ? It's too much of console > dialog > type scale > Enter. I am thinking either have dialog always up, or binding scaleModel cmd to a hot key (not sure if it's possible at all) or simply typing in the console (this is the quickest IMO) are optimal workflows.

 

Also wondering if it's possible to add "scaleModel reset", which would reset transformation matrix to original state ("1 0 0 0 1 0 0 0 1" as I recall).

 

Is it also possible to add "modelscale" "<scaleModel value>" spawnarg to the respective entity (or update it if the spawnarg already exists). "modelscale" spawnarg would be for Quake 3 compatibility, since DR can now be used for Quake 3 mapping.

 

Thanks beforehand!

[Scaling func_statics in DR - how to implement ?]

Thanks for the tips.

 

Now that I think about it more, I think the easiest would be making Python plugin where designer could type something like scale 1.5 in the console, and selected model would scale up. Basically Python script would get scale value, multiply matrix by it, and set updated spawnarg on the selected entity. Plus add scale spawnarg (for Quake 3).

 

Can someone savvy in DR and Python create such plugin please?

[OrbWeaver removed his Github account ?]

Thanks for clarifying this, OrbWeaver.

 

GitHub is Gitarded! Good thing I never gotten around to host anything there.

[OrbWeaver removed his Github account ?]

Gee.. WTF?! I am willing to bet those are americans

[OrbWeaver removed his Github account ?]

SJW? (sounds familiar, but not sure what that means )

 

Maybe they did. It makes no difference though :/

[OrbWeaver removed his Github account ?]

Pretty odd - orbweaver's account no longer exists on Github. Any idea what's happening?

[2 normal maps per model ?]

NPC's textures use addnormals, for example:

 

 

        bumpmap		addnormals( models/md5/chars/guards/citywatch/cityguard5_local, heightmap( models/md5/chars/guards/citywatch/cityguard_h, 2 ) )

 

 

 

Question is whether you can scale the heightmap or the second normalmap. I suspect it's not possible.

 

What is number "2" for in that line ?

[2 normal maps per model ?]

Here is an example made in Blender:

 

 

Top node tree is normal map #1, that is baked from high poly. That one doesn't tile.

 

Bottom node tree is normal map #2, aka "details" normal map. That one needs to tile.

 

When I set mapping to 1, 1, 1 in the video, it shows what Doom 3 engine does by default. It stretches normal map #2 to fit UV space of the model. And the goal is to have it tiling, like I show further in the video.

[Scaling func_statics in DR - how to implement ?]

Tested - all numbers in the matrix have to be multiplied by the scale factor. Before or after rotations - doesn't matter. So for uniform scaling it's easy. For non-uniform scaling it doesn't work.

 

Although no collisions on scaled models.

 

Now we just need to figure out how to add either "scale" field to entity inspector and multiply matrix or enable scaling in Arbitrary Transforms window.

[2 normal maps per model ?]

Anything is possible, I recall the roadblock to normal compression was mixing "grey-scale heightmaps" and normalmaps but it may be that BFG dropped heightmaps

altogether?

 

https://www.iddevnet.com/doom3/bumpmaps.php

 

BFG uses same materials and images as Doom 3.

[2 normal maps per model ?]

Sorry, I didn't read your question carefully. Greyscale images weight less than normalmaps and the effect is essentially the same.

 

It has nothing to do with weighting less. It's about tiling over the model vs stretching. I am gonna have to make an example since people get confused with this.

[2 normal maps per model ?]

 

I've been told we shouldn't be using addnormals because if/when we get normalmap compression it won't be compatible.

 

Doom 3 BFG uses compression for normal maps and works with addnormals. What it does it adds normal maps, and saves it into a new image, which gets compressed. All done automatically.

[2 normal maps per model ?]

Yes, it's a fact. But can you tile second map, whether it's normal map or bump map ?

[2 normal maps per model ?]

I recall when making masks, it can be scaled. I wonder if addnormals have scaling parameters too (for the second map).

[2 normal maps per model ?]

Yes, except those have to occupy the same UV space.

 

Imagine a model. Bake out normal map for it that represents major detail on the model. The image is 2048 x 2048. Then take a "detail" normal map, tileable, 512 x 512 size. If you do addnormals with those two, the first one will fit fine, but the second one will be stretch to fit UV space. I need for second one to be tiled over UV space and I should be able to set tiling parameters.