Support For Addnormals()

[greebo]

I recently discovered the addnormals() keyword to merge two normalmaps and applied it to some of my shaders. Firing up DarkRadiant revealed that it doesn't support this kind of bumpmap argument - all of the shaders using addnormals(x,y) appear as "shader not found" (and an error is written to radiant.log).

 

However, I could at least make the problem a little bit smaller by changing this part in shader.cpp:~444

 

  RETURN_FALSE_IF_FAIL(Tokeniser_parseToken(tokeniser, "("));
 RETURN_FALSE_IF_FAIL(Tokeniser_parseTextureName(tokeniser, bump));
 RETURN_FALSE_IF_FAIL(Tokeniser_parseToken(tokeniser, ","));
 RETURN_FALSE_IF_FAIL(Tokeniser_parseToken(tokeniser, "heightmap"));
 TextureExpression heightmapName;
 ShaderValue heightmapScale;
 RETURN_FALSE_IF_FAIL(Doom3Shader_parseHeightmap(tokeniser, heightmapName, heightmapScale));
 RETURN_FALSE_IF_FAIL(Tokeniser_parseToken(tokeniser, ")"));

 

(which is wrong as there is no "heightmap" in the syntax of addnormals()) to this

 

  RETURN_FALSE_IF_FAIL(Tokeniser_parseToken(tokeniser, "("));
 RETURN_FALSE_IF_FAIL(Tokeniser_parseTextureName(tokeniser, bump));
 RETURN_FALSE_IF_FAIL(Tokeniser_parseToken(tokeniser, ","));
 RETURN_FALSE_IF_FAIL(Tokeniser_parseTextureName(tokeniser, bump));
 RETURN_FALSE_IF_FAIL(Tokeniser_parseToken(tokeniser, ")"));

 

After changing this, the qer_editorimages are displayed correctly (as the parser goes over the definitions without throwing an error), but when switching to rendermode the normalmaps are still not displayed. This doesn't hurt me too much as I seldom use the rendermode of DarkRadiant, but it may be annoying for others.

 

According to https://zerowing.idsoftware.com/svn/radiant...iant/trunk/TODO the support for addnormals() is still on the ToDo-List, so perhaps this will be resolved in the future, perhaps not.

 

I would be grateful if you could merge the code changes above into SVN so that I can continue to use my shaders even after a clean checkout, because I find this keyword rather useful.

[OrbWeaver]

I've merged the workaround now, although this is still technically incomplete since addNormals() should accept recursive expressions: addNormals(addNormals(X, Y), Z) (but I imagine this is exceptionally rare). IN fact this whole section needs a rewrite, I can't believe anyone would use a control-flow macro like RETURN_FALSE_IF_FAIL these days (that's what god invented exceptions for).

 

This shouldn't be too hard to fix for rendering, the new combined normalmap could be generated at parse time and sent to the renderer in the usual way as a single map.

[greebo]

Thanks for merging. I don't know how fast the code can blend these two (or more) normalmaps, but this could increase the loading time of DR a lot, especially if we had a lot of shaders using this keyword.

 

If I had the choice I would do this at the point when it's required, i.e. right before switching to rendermode.

[Gildoran]

I don't know if now is the time to request it, but I've noticed that DarkRadient didn't seem to support shifting/scaling of stages... Is there any chance support for them could be added? (note: the D3ed preview doesn't get the scaling origin correct, so the game itself would need to be used as a model)

[greebo]

In fact this whole section needs a rewrite, I can't believe anyone would use a control-flow macro like RETURN_FALSE_IF_FAIL these days (that's what god invented exceptions for).

Hm. Perhaps this would be a smaller task for me to get my feet wet with coding? What do you think, Orbweaver? Is there already some sort of exception class existant?

[OrbWeaver]

Thanks for merging. I don't know how fast the code can blend these two (or more) normalmaps, but this could increase the loading time of DR a lot, especially if we had a lot of shaders using this keyword. If I had the choice I would do this at the point when it's required, i.e. right before switching to rendermode.

 

I take your point, but I think users will accept a slower startup more readily than a greater delay on switching to Render mode. The time you wait between pressing F3 and seeing any change is already unnacceptable in my view.

 

I don't think blending normalmaps would be THAT slow, I think you just have to overlay them and then do some renormalisation pass.

 

I don't know if now is the time to request it, but I've noticed that DarkRadient didn't seem to support shifting/scaling of stages... Is there any chance support for them could be added? (note: the D3ed preview doesn't get the scaling origin correct, so the game itself would need to be used as a model)

 

Yeah, the whole material processing thing needs a rewrite. I think that all it does at the moment is display the editorimage in non-lit mode and the diffuse/bump/specular in lighting mode, with no processing of the textures whatsoever.

 

Hm. Perhaps this would be a smaller task for me to get my feet wet with coding? What do you think, Orbweaver? Is there already some sort of exception class existant?

 

By all means, have a go at it if you like, although I haven't looked into this in detail so I can't specify exactly what is required beyond "code improvement" (and I'm pretty sure it won't be a small task). In general a recursive-descent parser that throws a ParseException of some sort is better than a depth-based parser with horrible macros to RETURN_FALSE_IF_FAIL, using a boost-based library is better than homegrown shit (see my libs/parser/DefTokeniser.h which is used in radiant/eclass_doom3.cpp to parse DEF files), and using proper C++ tools better than C-style ones (compare std::string's with a==b rather than string_equal_nocase(const char*, const char*)).

 

If you need to create a new exeption, just do what I have done with the exceptions in the xmlutil library -- they just inherit from std::runtime_error and pass their "what" argument up to the parent.

[Springheel]

Hm. Perhaps this would be a smaller task for me to get my feet wet with coding? What do you think, Orbweaver? Is there already some sort of exception class existant?

 

Gah. Are ALL our new coders working on the editor? We have lots of other programming tasks for the next milestone that aren't done yet.

[New Horizon]

Gah. Are ALL our new coders working on the editor? We have lots of other programming tasks for the next milestone that aren't done yet.

 

Ha ha, true...but I think it goes hand in hand. The faster we can make Dark Mod features easier to use in Dark Radiant, the faster we'll be able to see where we're falling short on the mod itself. I became frustrated trying to setup all the stuff I needed to build Dark Radiant from the source, so I'm anxiously awaiting the next release so I can try out the model viewer. How far down the line is a Stim/ Response GUI Orb?

[greebo]

By all means, have a go at it if you like, although I haven't looked into this in detail so I can't specify exactly what is required beyond "code improvement" (and I'm pretty sure it won't be a small task). In general a recursive-descent parser that throws a ParseException of some sort is better than a depth-based parser with horrible macros to RETURN_FALSE_IF_FAIL, using a boost-based library is better than homegrown shit (see my libs/parser/DefTokeniser.h which is used in radiant/eclass_doom3.cpp to parse DEF files), and using proper C++ tools better than C-style ones (compare std::string's with a==b rather than string_equal_nocase(const char*, const char*)).

 

If you need to create a new exeption, just do what I have done with the exceptions in the xmlutil library -- they just inherit from std::runtime_error and pass their "what" argument up to the parent.

Ok, I will have a try, but first I will start reading the code and some documentations, which surely will take some time. As soon as I dare to say that I understand everything that's going on, I will go and create some new parser. What kind of development environment are you using? Just a text editor and scons or are there easier ways that I'm unaware of?

 

Gah. Are ALL our new coders working on the editor? We have lots of other programming tasks for the next milestone that aren't done yet.

I want to take a look at the Dark Mod code as well, but I'm still chewing on sending sparhawk my public key (I hope I got it right this time ). Don't expect anything though, as I'm no C++ wizard or anything, but better try and fail than to leave it unattempted.

[OrbWeaver]

I became frustrated trying to setup all the stuff I needed to build Dark Radiant from the source, so I'm anxiously awaiting the next release so I can try out the model viewer. How far down the line is a Stim/ Response GUI Orb?

 

I haven't started Stim/Response yet -- once the Model Selector is complete (which it almost is), the next priority will be the media browser, then S/R and Objectives will come after that.

 

Ok, I will have a try, but first I will start reading the code and some documentations, which surely will take some time. As soon as I dare to say that I understand everything that's going on, I will go and create some new parser. What kind of development environment are you using? Just a text editor and scons or are there easier ways that I'm unaware of?

 

I use Eclipse with the CDT development tools. However on Windows this is painfully slow, so you might well be better off with a text editor + scons or a lightweight Windows IDE like Dev-C++.

 

If you want to contribute, perhaps N.H. can set you up as a Programming contributor, so you can see the outstanding Darkradiant tasks list we have in there. Rewriting the material parser is not a priority at the moment, it is just something that would be appropriate some time down the line.

[greebo]

I use Eclipse with the CDT development tools. However on Windows this is painfully slow, so you might well be better off with a text editor + scons or a lightweight Windows IDE like Dev-C++.

 

If you want to contribute, perhaps N.H. can set you up as a Programming contributor, so you can see the outstanding Darkradiant tasks list we have in there. Rewriting the material parser is not a priority at the moment, it is just something that would be appropriate some time down the line.

Ok, will try with one of those. I already read that thread as I can see those internal forums (since Wednesday I think). At first I thought I could have a try at Task No. 5 (Addition of "all light volumes" toolbar button), but it may be safer if I tried my marvellous skills at something that's not so mission-critical.

[OrbWeaver]

Ok, will try with one of those. I already read that thread as I can see those internal forums (since Wednesday I think). At first I thought I could have a try at Task No. 5 (Addition of "all light volumes" toolbar button), but it may be safer if I tried my marvellous skills at something that's not so mission-critical.

 

Don't worry, that's not mission critical. Most mappers don't even know that button exists in DoomEdit, not least because it is so far along the right of the toolbar that users with less than 1280x1024 can't even see it.

 

Actually, if you did want to look at that task, it might be an opportunity to change the toolbar layout to a "view" toolbar along the top and an "actions" toolbar down the side (like UnrealEd), to make things a bit easier for the lower-resolution users.

[New Horizon]

Actually, if you did want to look at that task, it might be an opportunity to change the toolbar layout to a "view" toolbar along the top and an "actions" toolbar down the side (like UnrealEd), to make things a bit easier for the lower-resolution users.

 

That would be nice actually.

[Crispy]

I use Eclipse with the CDT development tools. However on Windows this is painfully slow, so you might well be better off with a text editor + scons or a lightweight Windows IDE like Dev-C++.

For Windows, I use and recommend Notepad++ for editing code, and scons in a command window for compiling. Works nicely (though it sometimes takes ages to compile - but this is the fault of GtkRadiant's code design more than anything, and would happen using any compiler / build system, though certainly gcc is not what I'd call fast).

 

Dev-C++ is ok if you're using the compiler it comes with, but the code editing is pretty clunky. IMO Notepad++ is better, even though there's no built-in compile option. Just means you have to go Alt+Tab-Up-Enter to compile (via scons) instead of hitting F9.

[Gildoran]

Actually, I think you can add that via editing shortcuts.xml... Try adding this line:

<Command name="compile this file" Ctrl="no" Alt="no" Shift="no" Key="120">C:\mycompiler\compile $(CURRENT_WORD)</Command>

Unfortunately, support for user-defined languages sucks (it has terrible parsing, incapable of figuring out the difference between /* and / * and has no concept of escape characters for C-style strings), and I can't figure out how to get it to add more lines to the builtin language menu, so I'll be sticking with UltraEdit32 for now.

[greebo]

Is it possible to use Eclipse to set breakpoints and so on? Because at the moment I can compile and run DarkRadiant via Eclipse/scons, but as soon as I want to "debug" it instead of "run" it, it complains that the application is not responding or something. Is this the regular behaviour for GTK+ apps or is there something wrong with my debugger configuration?

[OrbWeaver]

You need to install GDB to get Eclipse/CDT's debugger to work. This is available from MinGW.

 

Unfortunately although this combination has worked for me in the past, it does seem to randomly stop working after a while (in fact this seems to be a common feature of Eclipse - functions that worked fine suddenly start giving stupid "internal error occurred" type messages).

 

Failing that, just use print statements. The only time I ever use a debugger is to analyse segfaults (where it gives you a very nice stack trace showing exactly which line caused the fault).

[OrbWeaver]

For Windows, I use and recommend Notepad++ for editing code, and scons in a command window for compiling. Works nicely (though it sometimes takes ages to compile - but this is the fault of GtkRadiant's code design more than anything, and would happen using any compiler / build system, though certainly gcc is not what I'd call fast).

 

I think it's MinGW which is slow - GCC on Linux has very good performance. I am not sure why the Windows port is so slow, but for some reason the final link of darkradiant.exe takes about 5 - 10 seconds on Linux and about 60 - 90 seconds on Windows.

[greebo]

I've installed GDB and it's working correctly with those "hello world"-type programs, but it does not with DarkRadiant:

 

 

But if it's not that important, I will stick to console outputs (as I've done before when I tried to figure out the problem with freezeTransform()).

[Crispy]

Unfortunately, support for user-defined languages sucks (it has terrible parsing, incapable of figuring out the difference between /* and / * and has no concept of escape characters for C-style strings), and I can't figure out how to get it to add more lines to the builtin language menu, so I'll be sticking with UltraEdit32 for now.

 

???

 

Are we talking about the same Notepad++? My copy handles / * properly, understands string escapes, and already handles C++ just fine, which is all I need it for.

[Gildoran]

Yes, but those are predefined languages... That doesn't seem to happen with user-defined languages. (if you can manage to create a user-defined languages that's equivelant to the C or C++ languages, please tell me!) I'd be perfectly happy with editing the xml files that determine the predefined languages, except that the list of predefined languages seems to be hard-coded rather than read from the language file at runtime.

[Crispy]

Ah, I see. Well, I don't use it for anything other than C++ programming so I don't really care about its support for user-defined languages.