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

DarkRadiant 2.2.0 pre-release testing

Recommended Posts

So I made a backup copy and then deleted all the layers. Deleting all the layers fixed the problem.

 

Should I still send over the original files for evaluation?

Edited by Dunedain19

Share this post


Link to post
Share on other sites

A new pre-release build (2.2.0pre2) is available in the first thread.

 

There's a new feature in there which needs some explanation: next to the QE/Translate/Rotate/Clip manipulator modes accessible in the toolbar on the left, there's a new button called "Model Scaler". It can be activated anytime, but it will only work when entities with models (static meshes, i.e. ASE or LWO models) are selected. Once activated, you can drag any of the corner points of that bounding box to resize the model. The changes will be written to disk the next time you save the map, when the resized model will be saved in ASE format to the models/map_specific/scaled/ folder.

 

scaler1.jpg scaler2.jpg

 

Notes about this:

- the model is fully functional, even in lighting mode, as the normals are scaled correctly using the inverse transpose matrix. You will still need to dmap for any changes to take effect, of course.

- the scaled folder is likely to collect some amounts of unused .ASE files when this feature is used excessively. I was thinking about a script to clean that up, but this is future talk.

- Vertex colours are preserved, at least that's what I coded in (haven't actually checked).

- the scaled ASE file is likely to be different than the original .ASE file as DarkRadiant is rearranging the model surfaces by shader during load.

 

A couple of other things have been added to this pre-release build as well, check the first post or the bugtracker for details.

Share this post


Link to post
Share on other sites

To save the forum software the overhead of processing 53,000 likes everytime the developers announce something cool like this, I guess

  • Like 2

Intel Sandy Bridge i7 2600K @ 3.4ghz stock clocks
8gb Kingston 1600mhz CL8 XMP RAM stock frequency
Sapphire Radeon HD7870 2GB FLeX GHz Edition @ stock @ 1920x1080

Share this post


Link to post
Share on other sites

Fantastic job greebo! This and grouping were fantastic additions to DarkRadiant, now there's few things we can't do with it compared to other editors!

 

Can you explain the process you went to doing this? Would be really cool topic IMO.

Share this post


Link to post
Share on other sites

Glad I found something helpful.

 

Can you explain the process you went to doing this? Would be really cool topic IMO.

 

What do you mean by process? The coding or what?

Share this post


Link to post
Share on other sites

Is just a request if you don't have time don't bother with it, i don't want to take you from other important tasks, Yes the coding but no need to go deep, is more why was it not implemented before and what did you do to make this happen and if some shortcuts were need, etc, i'm learning coding and i just love to know how other coders do to solve problems, and model scaling was something that even id didn't implemented on their editor.

Edited by HMart

Share this post


Link to post
Share on other sites

I think the idea has been there before, I believe the feature request to be able to scale models is something that has been mentioned a few times in the past. I don't remember exactly, but I was discussing DarkRadiant stuff with angua when she asked me whether this would be a possible approach (scaling stuff and saving the resized model as ASE). The years before I probably would have said that this is way too clumsy or I didn't want to mess with that parts of the code, but this time I thought why not have a go at it.

 

It required changing a few different areas in DR's codebase, I had to get the scaling itself right (the proof of concept for this was done pretty quickly, it's just matrix text book stuff), then I had to figure out how to write ASE files (which I knew was possible, especially since we already have a working Python exporter script) plus create a framework for exporting models, and lastly I had to figure out how the mouse-to-scene algorithms were working. That last thing was the hardest part for me. I haven't had my fingers in that area of the code (and it was pretty much undocumented, as all the legacy GtkRadiant stuff), and the calculations were somewhat obscure. I had to wrap my head around this, which took me a few days of research, discussions with angua, code reading and lots of pen and paper math. There's easy, standard stuff on the web, but there's virtually nothing to read about that specific case I needed to implement. Once I had that figured out, I could go ahead and refactor the selection code, such that I could add that new manipulator. Looking back at it, it just took a few hundred lines and it doesn't look hard anymore, but I guess that's what experience is about.

 

Nevertheless, the feature still has to prove itself in actual mapping. Maybe it isn't practical or maybe it has bugs or is causing trouble in the engine, let's wait and see.

Share this post


Link to post
Share on other sites

Admins really need a like button...

 

Thank you for the explanation, that is how i'm trying to learn as well, looking at code and trying to decifer it, but being a autodidact is not easy, and yes i assume tool making specially game editors is not something you can easely find in game literature but i'm not certain, i personally never saw a "make your own level editor for dummies" in any book store :P .

Btw is funny that the way you made scaling, is more or less how i imagined it could be implemented, i even talked about it here, i'm not trying to say you robed my idea or something, just happy my reasoning was correct. :)

 

By your last sentence may i assume you still didn't worked on the engine side? I still didn't try it but does it still messes up the collision model and shadow model?

 

p.s - IMO shadow model could become obsolete if shadow mapping was implemented so no problem if it gets messed up.

Edited by HMart

Share this post


Link to post
Share on other sites

By your last sentence may i assume you still didn't worked on the engine side? I still didn't try it but does it still messes up the collision model and shadow model?

There's no need to change anything on the engine side, since each size goes into its own, freshly generated ASE file. There's no rotation matrix hack involved which is known to screw up collision and normals (for lighting).

 

Disk and memory consumption are bound to increase the more models are scaled all around the place, so it has to be used with that in mind.

Share this post


Link to post
Share on other sites

I don't mean to sound ungrateful, but if a scaled mesh is saved as another mesh, that kind of contradicts its purpose (i.e. being loaded to memory once, but used multiple times, in many configurations).

Share this post


Link to post
Share on other sites

Is there a way to scale a model in only one direction at a time?

 

For example, I want to scale a fencing section to fit between two walls, but I don't want the fence to become taller or shorter.

Share this post


Link to post
Share on other sites

Yes, hold down the SHIFT key during resize to lift the proportional restriction.

Share this post


Link to post
Share on other sites

I just noticed that if I scale a model, and then copy and paste it, the pasted model reverts to its original size.

Share this post


Link to post
Share on other sites

I just noticed that if I scale a model, and then copy and paste it, the pasted model reverts to its original size.

Yes, cloned models are reverting to their originals (unless the map has been saved already). Fixing that behaviour is not quite as easy as it may sound, that's why I skipped it for the moment being.

Share this post


Link to post
Share on other sites

Next pre-release (pre3) build is up in the first post, with a couple of improvements over the previous one. The first post contains more details about what has changed.

 

I'd like to make this pre build the last one before the actual 2.2.0 release, so I'd appreciate it if people could confirm this version to be sane enough.

Share this post


Link to post
Share on other sites

Build from latest git fails under 32-bit Slackware 14.2, with wxWidgets 3.1.0:

 

Making all in wxutil
make[3]: Entering directory '/home/x/DarkRadiant-git/DarkRadiant/libs/wxutil'
  CXX      FreezePointer.lo
  CXX      ConsoleView.lo
  CXX      GLWidget.lo
  CXX      KeyValueTable.lo
  CXX      PanedPosition.lo
  CXX      VFSTreePopulator.lo
  CXX      WindowPosition.lo
  CXX      GLFont.lo
  CXX      PathEntry.lo
  CXX      TreeModel.lo
  CXX      TreeView.lo
  CXX      TreeModelFilter.lo
TreeView.cpp: In member function 'void wxutil::TreeView::ResetSortingOnAllColumns()':
TreeView.cpp:98:22: error: 'ResetAllSortColumns' was not declared in this scope
  ResetAllSortColumns();
                      ^

AFAICT, that's the only build error.

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...