Popular Post SteveL Posted March 16, 2014 Popular Post Report Posted March 16, 2014 (edited) UPDATE 29-Mar:Latest script version in this post: http://forums.thedar...post__p__341896Demo video (original) in this post: http://forums.thedar...post__p__340566Development discussion is in the thread on cutting patches with spreadsheets. I've done a demo video for this with use cases but I'm having to figure out how to get it onto YouTube (not done it before). With luck, I'll add it to this post this afternoon. To install the script:Save it to your DarkRadiant/scripts/commands folder, in the dark radiant install folder. Remove the .txt extension from the file name. Then click File > Reload scripts in DR, or just reopen DR. You can set up a keyboard shortcut using the normal menu. The tool is called "SplitPatch". To use it: Select one patch, enter vertex editing mode, and select 2-3 adjacent verts on the same line, including at least one pink vert (selecting 2 nearby pinks like I do in the video wherever possible will help the script run fastest). Then click Scripts > Split patch from the menu, or use your shortcut. Save the map beforehand and don't rely on Undo. You *can* undo -- press it twice -- but the verts you originally selected will be on grid but a bit out of place. Another side effect is it leaves your orthoview in top-down view no matter where you started. Please watch out for bugs. Most of this code was written yesterday! I've used it for a few hours without problems. There's sometimes a couple of seconds' delay using the tool. There's a lot going on under the hood. If people find that's a problem on bigger maps, I'll look for ways to optimise it. attachment=patchsplitter.py.txt (updated version linked above) EDIT: Updating the instructions to reflect what I currently think's optimal. Edited March 29, 2014 by SteveL 9 Quote
nbohr1more Posted March 16, 2014 Report Posted March 16, 2014 YES! Quote Please visit TDM's IndieDB site and help promote the mod: http://www.indiedb.com/mods/the-dark-mod (Yeah, shameless promotion... but traffic is traffic folks...)
Bikerdude Posted March 16, 2014 Report Posted March 16, 2014 Where is the demo vid..? as I am trying something I have wanted to since I started maping years ago but I keep getting told I cant do it etc etc.. Quote
Popular Post SteveL Posted March 16, 2014 Author Popular Post Report Posted March 16, 2014 (edited) I have it ready but I can't figure out how to embed it! For now, here's a link: http://youtu.be/R1FdElYIjnk I did pick up on that suggestion of yours for the vid... EDIT: Ah, THAT'S how you embed a video! Edited March 16, 2014 by SteveL 5 Quote
Bikerdude Posted March 16, 2014 Report Posted March 16, 2014 Sweet, I had figure out how to do by added more colums which then gave me the pink vert points i needed. nice vid btw, I didnt even know about "bulge" option untill I saw it in your vid, well done that man! the only isseue and its a DR limitation is when you add vert to a cylynder it does so on one bloody side, the mapper then has to move all the vert to they are equally spaced etc. How hard would it be to join patches..? eg if you have a long run of carpet in the shape of an L could that sorta patch be rejoined..? patch_split.map.txt Quote
grayman Posted March 16, 2014 Report Posted March 16, 2014 I've spent many a night fitting curved patches to door and window openings. It's great to know that that life is now over, and I can now look forward to a new life filled with bubbling streams, fields of spring flowers, rabbits hopping hither and yon, butterflies - Um, well, you know. This is brilliant. 1 Quote
SteveL Posted March 16, 2014 Author Report Posted March 16, 2014 Sweet, I had figure out how to do by added more colums which then gave me the pink vert points i needed. nice vid btw, I didnt even know about "bulge" option untill I saw it in your vid, well done that man! the only isseue and its a DR limitation is when you add vert to a cylynder it does so on one bloody side, the mapper then has to move all the vert to they are equally spaced etc. How hard would it be to join patches..? eg if you have a long run of carpet in the shape of an L could that sorta patch be rejoined..? patch_split.map.txtThey can be stitched automatically... let's have a think how that would work. I do want to add to the patch toolkit. Yes the verts getting added at one side is a pain. It's less painful when you get the hang of moving pinks only first, but still a pain. You just caught me making notes about how a script could do it. Take all the verts of a cylinder or circle, redistribute them, at the same time fixing a perfect circle, then fix the texture stretching. DR's python API can easily handle all that. Haha, cheers grayman Quote
Bikerdude Posted March 16, 2014 Report Posted March 16, 2014 Take all the verts of a cylinder or circle, redistribute them, at the same time fixing a perfect circle, then fix the texture stretching. DR's python API can easily handle all that.Awesome, and yes as you noticed DR dosent make proper circles atm, they are sorta squarish etc. Now if we could fix the way textures are copied and pasted from brushes to patches that would also be a part of a mappers life he or she can do without.. Quote
grayman Posted March 16, 2014 Report Posted March 16, 2014 Awesome, and yes as you noticed DR dosent make proper circles atm, they are sorta squarish etc. That's an old problem. Unfortunately, true circles can't make use of the "cap patch" feature. That only works with the squarish circles. Quote
SteveL Posted March 16, 2014 Author Report Posted March 16, 2014 That's an old problem. Unfortunately, true circles can't make use of the "cap patch" feature. That only works with the squarish circles. Ah, that's useful to know. Do you know whether it's logically impossible, or just not implemented yet? Quote
RJFerret Posted March 16, 2014 Report Posted March 16, 2014 Awesome script! OMG would have made life SO much easier back in November when I was going crazy with patches. ;-) This will save hours upon hours, thank you SO much. Usability issue, "You've selected the existing seam of a 3D patch. It's already cut there, so no action has been taken." That is reported when I selected two pink verts in the middle of edges on a 5x5 patch. IE, something that may be cut. The patch isn't already cut there, it's the middle of a 5x5. What was needed was to select ALL the pink verts, then it works fine. Is there any way to provide a progress bar? It currently just keeps the UI frozen, which would be the exact same feedback as if it was stuck in a loop. I was using it on a small map, just 2355 brushes and 1725 entities and it was several seconds. Based on how it currently works, I would probably change, "Bad selection. Select one patch only, and 2 or more verts from the same (pink) row or column." to read "Bad selection. Select one patch only, and all pink vertices from the same row or column." Again, big props and appreciation! Quote "The measure of a man's character is what he would do if he knew he never would be found out."- Baron Thomas Babington Macauley
grayman Posted March 16, 2014 Report Posted March 16, 2014 I don't know how the cap code works. I know of no plans to implement true circles. I was given a prefab circular cylinder to use in places where having a circle was preferred over having a squarish circle. DR will not create caps for it. Quote
SteveL Posted March 16, 2014 Author Report Posted March 16, 2014 (edited) Awesome script! OMG would have made life SO much easier back in November when I was going crazy with patches. ;-) This will save hours upon hours, thank you SO much. Usability issue, "You've selected the existing seam of a 3D patch. It's already cut there, so no action has been taken." That is reported when I selected two pink verts in the middle of edges on a 5x5 patch. IE, something that may be cut. The patch isn't already cut there, it's the middle of a 5x5. What was needed was to select ALL the pink verts, then it works fine. Thanks. You found the first fixable bug! In the meantime, you don't need to select every pink vert, you just need to avoid selecting only edge verts at the opposite end of a line . It's a false positive on the test for the user selecting a 3d seam -- the only time that gets triggered is when you have verts in both row/col 0 and the final row/col selected. It hadn't occurred to me that people might do that deliberately as you did. Is there any way to provide a progress bar? It currently just keeps the UI frozen, which would be the exact same feedback as if it was stuck in a loop. I was using it on a small map, just 2355 brushes and 1725 entities and it was several seconds. I don't think so I'm afraid. I don't think we have non-modal dialogs. I will think about how to optimise it... It works quite fast in test maps, but I was afraid a big map might slow it.One thing is, it works much faster when it succeeds in finding the verts quickly. When you give it a difficult one or one that's going to error, it'll freeze for much longer. What's going on is that the search algorithm is repeating at ever lower grid sizes to try to determine a valid selection. I can probably cut a lot of that out if I profile the results and see what grid size they mostly come from. I suspect that the expensive, small-grid searches rarely return good results when the others have failed. It needs a bit more testing and tuning to speed it up, which it'll get Edited March 16, 2014 by SteveL Quote
SteveL Posted March 16, 2014 Author Report Posted March 16, 2014 Thinking about it RJF, you could test that on your map if you get a moment and see whether it improves things. If you open the .py file, there are a couple of constants at the top. MINGRIDPOWER is set to -1 (=grid 0.5) which is probably way too small. i would try setting that to 2 (=grid size 4) and see if it helps. Quote
RJFerret Posted March 16, 2014 Report Posted March 16, 2014 Go me! I might've found a second bug too... Sadly minpower of 2 threw an error, "Unable to determine selected verts.", as did a minpower of 1. (With the same verts selected as the prior test before changing it from -1, which took 10 seconds by the way.) Returning it to -1 restored functionality. Quote "The measure of a man's character is what he would do if he knew he never would be found out."- Baron Thomas Babington Macauley
SteveL Posted March 16, 2014 Author Report Posted March 16, 2014 (edited) Thanks for trying that. Ok, so we probably do need fine-grid searches. Have you tried selecting adjacent vertices like I do in the video by the way? That's been working for me. I think 2 adjacent pink verts is probably optimal, with or without the intervening green vert. Must look at an api proposal. Accessing the selected verts directly would cure both the detection and speed issues. EDIT: NB the main problem the script has to deal with is false positives, not lack of results. The fewer verts you select and the closer they are together, the better the chance of success should be. Edited March 16, 2014 by SteveL Quote
RJFerret Posted March 17, 2014 Report Posted March 17, 2014 (edited) Whelp, here's my results, still using the same 5x5 patch. Select the nearest pink vert and middle vert, 15 seconds (ran twice). Select all the verts (three pink and two green, by shift dragging a box), still 10 seconds. Ditto doing the row instead of column (drag box, 10 seconds; select two neighboring pink verts, 15 secs.) Curious it doesn't match expectations. Edit: And just tested alerting the min to "1", tried with just nearest pink and center pink, still threw error. Edited March 17, 2014 by RJFerret Quote "The measure of a man's character is what he would do if he knew he never would be found out."- Baron Thomas Babington Macauley
AluminumHaste Posted March 17, 2014 Report Posted March 17, 2014 Yeah that's a lot easier than the way I had on the wiki lol. Now we just need Greebo to add it to dark radiant Quote I always assumed I'd taste like boot leather.
ungoliant Posted March 17, 2014 Report Posted March 17, 2014 grats on getting this done! dawn of a new DR era! Quote
SteveL Posted March 17, 2014 Author Report Posted March 17, 2014 Yeah that's a lot easier than the way I had on the wiki lol. Now we just need Greebo to add it to dark radiant Thanks, but not with this implementation! This works as a stop gap but it's very inefficient and has those side effects. I need a bit more time to work on it before showing anything to greebo! Quote
SteveL Posted March 17, 2014 Author Report Posted March 17, 2014 (edited) Curious it doesn't match expectations. Yes it is. I didn't have to do any cherry-picking to come up with the examples in the video. I just laid out what I wanted to show and it worked as you see it. I can see how a bigger map could slow it down, but I don't understand how its ability to find the right selected verts could be affected. I'll have a go tonight using your setup of a small patch with a big map, and see whether I can reproduce your difficulties and see what's going on. Edited March 17, 2014 by SteveL Quote
SteveL Posted March 21, 2014 Author Report Posted March 21, 2014 (edited) Whelp, here's my results, still using the same 5x5 patch. Select the nearest pink vert and middle vert, 15 seconds (ran twice). Select all the verts (three pink and two green, by shift dragging a box), still 10 seconds. Ditto doing the row instead of column (drag box, 10 seconds; select two neighboring pink verts, 15 secs.) Curious it doesn't match expectations. Edit: And just tested alerting the min to "1", tried with just nearest pink and center pink, still threw error. I can reproduce the slowness (9 seconds max on the biggest patch I could find in one of the biggest maps I had in my FMs folder), but not the difficulty / errors. It still runs fast (< 1 second) for me in a map with 2k entities and 5k brushes, but slows down noticeably when you double that. That'll depend on system speed and available memory of course. If it works, 10 seconds compares well with a spreadsheet or doing it manually, but you are seeing errors / refusal to cut the patch too. I've not been able to reproduce the errors. I've tried a FS patch (you have to have the patch component selected, not the whole FS), I've tried floors and cones, I've tried it in 1.8.0 and in the 1.8.1 pre-release version. I haven't yet failed to cut a patch, so I'm stuck on how to fix your issue RJF. Has anyone else suffered the same? It might have to wait for the proper solution rather than this workaround :-\ This is a rough hack of course, but disappointing that it works so well for me but not for everyone. EDIT: @RJF: If you still have time and inclination to help me get the workaround sorted, I could provide you a "verbose" version of the script that'll speel out console output, and I'd be able to compare that output with what I get. EDIT 2: Another thing that indicates something different is happening when you run it is that you got different output with a minimum grid > 0.5. My tests are terminating the search with a higher grid size, roughly half the distance between the patch verts, which is what I'd expect. NB it always starts the search with your current grid size, whatever that is, and increases it or decreases it as necessary. But that gives me a new idea: calc the average vert distance first and set the starting grid size accordingly. Edited March 21, 2014 by SteveL Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.