Create an account


Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
NetRadiant-custom

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

[Image: unknown.png]
Made of brush cubes
[Image: radDarkShot.png]

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

#2
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.
Xonotic exists for a long time and low player count is the proof that nobody wants to play Xonotic since it is a bad game by default.
- Lyberta, 2017
Reply

#3
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
Xonotic exists for a long time and low player count is the proof that nobody wants to play Xonotic since it is a bad game by default.
- Lyberta, 2017
Reply

#4
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?
Reply

#5
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
Reply

#6
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
Reply

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

#8
Any news about any effort that would make a merge to upstream easier?
This comment is licensed under cc by 4 and antecedent.
Reply

#9
No.
Reply

#10
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.
[Image: 230.png]
Reply

#11
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.
Reply

#12
(07-09-2019, 05:49 AM)_para Wrote: 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).
Reply

#13
@_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.
Reply

#14
@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.
Reply

#15
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?
Reply

#16
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.
Reply

#17
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.
Reply



Possibly Related Threads...
Thread Author Replies Views Last Post
  [NEED HELP] Custom Skins 3agle427 0 267 01-14-2019, 08:01 PM
Last Post: 3agle427
  [NEED HELP] NetRadiant Models Not Working 3agle427 1 354 01-13-2019, 04:53 AM
Last Post: SpiKe
  [NEED HELP] NetRadiant Bots 3agle427 1 221 01-11-2019, 09:35 AM
Last Post: Lyberta
  [NEED HELP] NetRadiant Window 3agle427 4 290 01-11-2019, 08:54 AM
Last Post: Julius
  [NEED HELP] NetRadiant Gravity 3agle427 0 169 01-09-2019, 08:58 PM
Last Post: 3agle427
  [NEED HELP] NetRadiant Func_Destructable 3agle427 6 360 01-08-2019, 07:57 AM
Last Post: 3agle427
  [NEED HELP] NetRadiant Weapon Respawn 3agle427 3 277 01-05-2019, 06:22 PM
Last Post: 3agle427
  [NEED HELP] NetRadiant Triggers/Destructables 3agle427 2 264 01-03-2019, 10:28 AM
Last Post: 3agle427
  [NEED HELP] Custom NetRadiant Textures / Textures Not Loading 3agle427 2 377 12-30-2018, 09:21 AM
Last Post: 3agle427
  Defining custom particle effect types Notavi 2 375 08-05-2018, 06:31 AM
Last Post: Notavi

Forum Jump:


Users browsing this thread:
1 Guest(s)

Forum software by © MyBB original theme © iAndrew 2016, remixed by -z-