![]() GTK guys are already preparing GTK4 and some distros already talk about ditching GTK2. As someone said, the Garux's radiant also misses all the ongoing UI rewriting effort that would make possible to ditch GTK2 one day. So, to answer to that question, it's a very bad idea to ditch upstream Netradiant for Garux's fork, this is why:īecause 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. ![]() I would like to see his contributions merged upstream, really. So please don't assume I have something against someone, assume I'm not normal instead.Īlso, Garux's contributions are welcome, and I am very thankful for when he helped me personnally on some topics. It's very important I say that because in such situation it's expected normal people get angry toward each other. I need to state that I have absolutely nothing personnally against Garux. (07-09-2019, 05:49 AM)_para Wrote: How about just ditching the official netradiant for it? Why or why not?įirst, I have to do a disclaimer before answering to that question. I know it's my own stipidity but such feedback just makes that more conventient. Often enough with the slice tool I want to drag the points but click next to them which creates a new point. Like the one you hover over gets a bit bigger. 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. Maybe being able to change the algorithms direction. 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. 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. Well I mostly use subtraction to fit detail like above or cur out doors.Ī smarter way of doing this could be a tunnel cutout tool. The ground detail was fitted by subtracting and there were plenty brushes that could be merged. ![]() That makes the computation somewhat more demanding.īut for example here where no pizza was involved(at aruond 13sec): 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.Īh now i get the pizza thing. (can be optimized so it may not be possible to double-check pairs if i and j are just swapped but well) If selection != false then -it wasnt merged Selection = selection = false -replace the old array brushes with false for later checkingįor i = 1, #selection do -append all non-merged brushes to the new array which weren't touched in the previous loops Local is_merged,new_brush = trymerge(selection, selection) If i != j and selection != false and selection != false then -dont merge with itself and not if its already merged Function recursive_merge(array selection)
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |