NetRadiant-custom

https://github.com/Garux/netradiant-custom
https://github.com/Garux/netradiant-custom/releases
Update has recently happened, with some evil features:


Made of brush cubes


To enable xonotic support you got to copy radiant/games/xonotic.game file and radiant/xonotic.game folder from your trusted source.

I tried it out and I like it. Original Netradian and q3map2 had some issues with geometry on my map(s), but this one seemed to handle things just fine.

Ok. About everytime I try compiling a map with a slick surface on it, the slick surface isn't actually slick for some reason. Then I use regular normal radiant, and compile again, now there's slick. WTF

Is weird, as i haven't touched related parts of the code. Are you sure, that both programs see the same slick shader? Can you send a map to reproduce named behavior?

For me it works perfectly with slick stuff. The slick part is just defined by a line in the .shader file so it shouldn't affect stuff in the radiant at all.

But if you're on windows try the radiant as I set it up. I think I replaced the compiler(q3map2.exe) with some different so it can handle more ram without crashing (else it's garux precompiled built of an older generation):
http://www.mediafire.com/file/z4uwva2fcy...180707.zip

32 bit win build already have q3map2 with > 2 Gb aware flag, which enables RAM usage up to 4 Gb
q3map2 from 64 bit build may taste all the RAM you'v got
named issue may be 64 bit specific in theory; a couple of such issues were noticed in 64 bit radiant build
q3map2 of this fork got a few decent improvements btw; also autocaulk in wip version wont work with different q3map2

Update!
https://github.com/Garux/netradiant-cust...g/20190705
With UV Tool and Autocaulk.

Any news about any effort that would make a merge to upstream easier?

No.

It's really a shame to see such enhancements made on a divergent fork where no team efforts can be made to improve NetRadiant as a whole... Hopefully that can change when you become a bit more familiar with Git.

How about just ditching the official netradiant for it? Why or why not?

I've been using garux' branch since I found out about it and now it's a pain going back. It makes the mapping workflow by far easier and more enjoyable.


@garux:
I have a request and maybe it's even feasible or fun to do: when subtracting brushes from one another the surrounding new brushed often can be merged. How about automatically trying to find mergable brushes afterwards.
OR a tool that can be substituted to also do above things: Automatically merge everything selected that ban be.
It could be a greedy approach where you just merge the best first recursively until none left or a more dijkstra approach where you look for the best result/least remaining brushes/fewest small remaining brushes(if the algorithm is in place it's just a change of a variable to adjust for the best result). Maybe that could be challenge you're up to. Or not.

How about just ditching the official netradiant for it? Why or why not?

I've been using garux' branch since I found out about it and now it's a pain going back. It makes the mapping workflow by far easier and more enjoyable.

There have been a lot of fixes and improvements in the official netradiant. Especially important for the future are all the commits that prepare moving the code from GTK2 to another GUI framework (probably GTK3 or Qt). GTK2 already makes problems with MacOS, it surely won't get better. If any version of netradiant wants to survive the next years, this has to be done (and will also improve the situation on Windows).

@_para , subtraction result depends on what exactly is subtracted; is it producing mergable brushes after subtraction of multiple brushes cpecifically?
Bruteforce merge would be nice to have in some cases. Good implementation is questionable: if checking mergability just for pairs of brushes during bruteforcing, may miss some possibilities, for example imagine a pizza, split to 3 slices in a classic manner. Trying all the pairs, triples and more might be time consuming on the other hand.

@freddy thanks

@garux:
You don't have to try triples and up because if you merged 2 brushes where 3 would fit the third still can be merged to that one later(1+1+1 = 3; 1+1 = 2+1 = 3 ). I can give you a pseudocode lua-styled example:

Code:

function recursive_merge(array selection)
    
    local array new_selection

    for i = 1, #selection do
        for j = 1, #selection do

            if i != j and selection[i] != false and selection[j] != false then --dont merge with itself and not if its already merged

                local is_merged,new_brush = trymerge(selection[i], selection[j])

                if is_merged then
                    new_selection[#new_selection+1] = new_brush
                    selection[i] = selection[j] = false --replace the old array brushes with false for later checking
                end

            end

        end
    end

    for i = 1, #selection do --append all non-merged brushes to the new array which weren't touched in the previous loops
        if selection[i] != false then    --it wasnt merged
            new_selection[#new_selection+1] = selection[i]
        end
    end

    recursive_merge(new_selection)

end

--initiate with an array of brushes:

recursive_merge(some_selection_array)

(can be optimized so it may not be possible to double-check pairs if i and j are just swapped but well)

The missing of possibilities can be worked around with a dijkstra approach that checks all mergable pairs in each order and tries to optimize for least remaining brushes or by brush volumes.

Imagine a pizza, split to 3 slices in a classic manner. No mergable pairs are available there.

Overall i think that such feature would be useful for mergable brushes, coming from external sources, for example decompiled model autoclip or some map generator, producing prisms.
Subtracting and basically concave geometry is not very natural for convex primitives.
May be we should invent tools to build things, which you are creating by subtraction, in a smarter way?

Ah now i get the pizza thing... yes you're right. That makes the computation somewhat more demanding.

But for example here where no pizza was involved(at aruond 13sec):


The ground detail was fitted by subtracting and there were plenty brushes that could be merged.

Well I mostly use subtraction to fit detail like above or cur out doors.
A smarter way of doing this could be a tunnel cutout tool. Like the slice tool but you define a rectangle and a direction and it cuts it out without having to create a brush for it. But I don't know if such tool is justified because you can just have that shape to cut out which also gives more control.
Or a cutout preview. So you can see how it would split stuff. Maybe being able to change the algorithms direction.

One small addition I'd ask tho would be some visual feedback for points you can drag with the mouse that indicate when you would grab them. Like the one you hover over gets a bit bigger.
Often enough with the slice tool I want to drag the points but click next to them which creates a new point. I know it's my own stipidity but such feedback just makes that more conventient.

I see, this is a good example of wanted geometry to consider. Substraction seems the best solution for this so far.
Slice tool points change their colour on mouse hover.

How about just ditching the official netradiant for it? Why or why not?

First, I have to do a disclaimer before answering to that question. I need to state that I have absolutely nothing personnally against Garux.
It's very important I say that because in such situation it's expected normal people get angry toward each other. So please don't assume I have something against someone, assume I'm not normal instead.
Also, Garux's contributions are welcome, and I am very thankful for when he helped me personnally on some topics. I would like to see his contributions merged upstream, really.

So, to answer to that question, it's a very bad idea to ditch upstream Netradiant for Garux's fork, this is why:

Because Garux's radiant is based on a 5 years old tree and lacks a lot of improvements made to the source base itself to make it able to survive the future, for example the Garux's radiant still relies on the Makefile solution which becomes hard to maintain. As someone said, the Garux's radiant also misses all the ongoing UI rewriting effort that would make possible to ditch GTK2 one day. GTK guys are already preparing GTK4 and some distros already talk about ditching GTK2. Worst than that, some part of code introduced by Garux introduces stuff that is already deprecated by GTK2 itself, meaning the added code makes the effort to ditch that obsolete GTK2 less possible, which is the exact opposite direction to the one that must be followed to make sure the project is viable for the mean term. All this effort made on upstream NetRadiant is about making NetRadiant able to run on macOS again, and to make sure NetRadiant will continue to build on Linux and Windows in the future. While trying to merge some code from Garux's tree I discovered that Garux's fork is going to the exact opposite direction.

Then, Garux's radiant has no peer review so anything can be merged without people asking for a rewrite before merge. This also explains why the UI code is going toward the past because no one warns Garux about this. The other reason why UI code is going toward the past is the miss of the new build chain based on CMake that was tailored to raise such issues automatically at build time. Because it's based on that 5 years old tree the Garux's fork also lacks a lot of code modernization to make it future proof, and that part is not related to UI, it's about the overall code.

Then the upstream NetRadiant get continuous improvements, ditching those improvements would be a loss. The best solution would be to merge the two branches, but that's very hard to do because of some mistakes Garux did in the early time of his fork. Basically Garux squashed hundreds of commits, mixing them with custom code that is now very hard to identify, isolate and pick. This is a very big issue for anyone. It makes Garux's radiant merging into upstream NetRadiant very hard, but it also makes upstream NetRadiant merging into Garux's radiant very hard. Garux is not helping himself on that part. It's easier to cherry pick from upstream NetRadiant to Garux's radiant than the other way, but that's not thanks to Garux's work, that's thanks to the efforts made by the Xonotic team and myself to make cherry-picking possible. Cherry-picking is when you just pick one change from another tree.

Note that I made a lot of efforts to make the merge possible:

First I wrote a tool to compare radiant trees. This was done before I discover Garux's fork, I used that tool to merge the iqm model plugin from aaradiant, for example.

First I offered Garux my help to fix his fork to make the merge of both trees possible, but after two years I'm still waiting for any effort on his side. It looks like Garux believed at this time that “helping” was “doing someone else's work”. I was ready to invest hundreds of hours to help him, but this is not “helping” if he expects I do all the job without his cooperation and without even knowing if my effort would be used one day. When I ask Garux how we can exchange code between trees, Garux answers I'm asking the wrong person and says that effort is up to others.

Then I taught Garux to correctly cherry-pick commits from upstream NetRadiant to be sure his newer commits are less hard to merge than his older ones. I'm basically helping him to improve his fork with the code written by the Xonotic team and myself while I see no one effort from Garux to make the opposite possible. It's unfair and no one would blame me if I were not helping him.

Then I reverted the code restyle that was done on the upstream tree after Garux forked NetRadiant, to make possible again (but still very hard) a merge from Garux's fork to upstream code tree.

Then I tried to merge some code from Garux (and without help from Garux), that's while doing that effort I discovered that Garux introduces GTK2 deprecated code, making the code quality regressing over time. By attempting to merge some of Garux code I also discovered that the code base would end with 3 unzip libraries, two of them conflicting.

So you now know I already spent dozen of hours to make a merge from Garux to upstream possible, but I'm yet to see a lone second being spent on that purpose from the other side.

You can see yourself how Garux react when I ask him if he has any news about any effort that would make the merge to upstream easier, he just laconically answers “No.”.

So, Garux's radiant is a very sad story, and unfortunately we now have one more radiant fork to add to the list.

Note that it would be hard to prevent people to be angry at Garux himself because of this sad story. I don't think it's a good idea to be angry at people so I'm not. Not being sad makes me able to wait for his willingness, and I'm still waiting for his good will. Garux knows I can help him if he is ok to get some help. But I have to say that giving help to someone else is not doing someone else's job neither working without him.

Note that some years ago some people (including Garux) suffered from merge requests not being reviewed for months (years), in this situation it's inevitable to see some trees living outside of the upstream one without getting merged (that's not contributor fault). But that's now fixed since years : I became a maintainer and I can review anyone's code and merge it quickly. So, the excuse of the upstream being slow to review or merge is not true since years, only the lack of will can explain the lack of merge request being submitted.

How about just ditching the official netradiant for it? Why or why not?

I've been using garux' branch since I found out about it and now it's a pain going back. It makes the mapping workflow by far easier and more enjoyable.


@garux:
I have a request and maybe it's even feasible or fun to do: when subtracting brushes from one another the surrounding new brushed often can be merged. How about automatically trying to find mergable brushes afterwards.
OR a tool that can be substituted to also do above things: Automatically merge everything selected that ban be.
It could be a greedy approach where you just merge the best first recursively until none left or a more dijkstra approach where you look for the best result/least remaining brushes/fewest small remaining brushes(if the algorithm is in place it's just a change of a variable to adjust for the best result). Maybe that could be challenge you're up to. Or not.

There was a particualrly frustrating time while building a map that when I build using Garux's fork, I couldn't get the ground to be slick. But the map repository as is, when built with normal netradiant, everything was completely fine.


I can admit the enhancements in Garux's fork is real nice, but I steered towards normal netradiant ultimately. I'm really not sure why the fork stemmed from a very old build because it seems having these integrated in normal netradiant would be amazing. (Or maybe that was the purpose... since the splash intro was changed and all.)

@Antares* Can you send a test map to reproduce named slick behavior?

@Antares* Can you send a test map to reproduce named slick behavior?

It was while I was editing one of my existing maps, not a new project that'd be a minimal demonstrative example.

Can you create simple reproducible case quickly? Because i have tried, and slick works (xonotic-0.8.2-mappingsupport.zip, xonotic-0.8.2.zip, works with both included and custom netradiants).

As for stemmed from a very old build, this stands for 'downloaded freshest netradiant code and started modifying it'; Later regular netradiant repo got massive code modernizations, which made swapping codes predictably complicated. So base is technically old, in terms of time passed.

Update!
https://github.com/Garux/netradiant-cust...g/20200320

Update!
https://github.com/Garux/netradiant-cust...ses/latest

Update!
netradiant-custom-20240226

https://github.com/Garux/netradiant-cust...tag/latest



letsgo