Jump to content


Photo

Patch splitting in Dark Radiant -- New version 29 Mar


29 replies to this topic

#1 SteveL

SteveL

    Hero Coder

  • Active Developer
  • PipPipPipPip
  • 3669 posts

Posted 16 March 2014 - 07:53 AM

*
POPULAR

UPDATE 29-Mar: 
Development 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 by SteveL, 29 March 2014 - 09:48 AM.

  • PranQster, Dragofer, Shadowhide and 6 others like this

#2 nbohr1more

nbohr1more

    Darkmod PR, Wordsmith

  • Development Role
  • PipPipPipPipPip
  • 8043 posts

Posted 16 March 2014 - 09:11 AM

YES!
Please visit TDM's IndieDB site and help promote the mod:

http://www.indiedb.c...ds/the-dark-mod

(Yeah, shameless promotion... but traffic is traffic folks...)

#3 Lux

Lux

    Advanced Member

  • Member
  • PipPipPip
  • 1575 posts

Posted 16 March 2014 - 09:15 AM

Excellent tool, thank you!

#4 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 18736 posts

Posted 16 March 2014 - 09:16 AM

HELL YES!

#5 grayman

grayman

    Master Builder, Coder

  • Active Developer
  • PipPipPipPipPip
  • 11921 posts

Posted 16 March 2014 - 09:20 AM

Thanks!

#6 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 18736 posts

Posted 16 March 2014 - 09:44 AM

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

PATCH_SPLIT.JPG

#7 SteveL

SteveL

    Hero Coder

  • Active Developer
  • PipPipPipPip
  • 3669 posts

Posted 16 March 2014 - 09:52 AM

I have it ready but I can't figure out how to embed it!

For now, here's a link:

I did pick up on that suggestion of yours for the vid...

EDIT: Ah, THAT'S how you embed a video!

Edited by SteveL, 16 March 2014 - 09:53 AM.

  • Flanders, Moonbo, Lux and 1 other like this

#8 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 18736 posts

Posted 16 March 2014 - 10:02 AM

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

Attached File  patch_split.map.txt   13.48KB   250 downloads

#9 grayman

grayman

    Master Builder, Coder

  • Active Developer
  • PipPipPipPipPip
  • 11921 posts

Posted 16 March 2014 - 10:06 AM

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

This is brilliant.
  • SteveL likes this

#10 SteveL

SteveL

    Hero Coder

  • Active Developer
  • PipPipPipPip
  • 3669 posts

Posted 16 March 2014 - 10:08 AM

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

Attached File  patch_split.map.txt   13.48KB   250 downloads

They 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 :)

#11 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 18736 posts

Posted 16 March 2014 - 10:11 AM

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

#12 grayman

grayman

    Master Builder, Coder

  • Active Developer
  • PipPipPipPipPip
  • 11921 posts

Posted 16 March 2014 - 10:33 AM

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.

#13 SteveL

SteveL

    Hero Coder

  • Active Developer
  • PipPipPipPip
  • 3669 posts

Posted 16 March 2014 - 11:05 AM

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?

#14 RJFerret

RJFerret

    Advanced Member

  • Member
  • PipPipPip
  • 1066 posts

Posted 16 March 2014 - 11:07 AM

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!
"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

#15 grayman

grayman

    Master Builder, Coder

  • Active Developer
  • PipPipPipPipPip
  • 11921 posts

Posted 16 March 2014 - 11:08 AM

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.

#16 SteveL

SteveL

    Hero Coder

  • Active Developer
  • PipPipPipPip
  • 3669 posts

Posted 16 March 2014 - 11:20 AM

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 by SteveL, 16 March 2014 - 11:34 AM.


#17 SteveL

SteveL

    Hero Coder

  • Active Developer
  • PipPipPipPip
  • 3669 posts

Posted 16 March 2014 - 11:30 AM

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.

#18 RJFerret

RJFerret

    Advanced Member

  • Member
  • PipPipPip
  • 1066 posts

Posted 16 March 2014 - 12:28 PM

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

#19 SteveL

SteveL

    Hero Coder

  • Active Developer
  • PipPipPipPip
  • 3669 posts

Posted 16 March 2014 - 12:38 PM

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 by SteveL, 16 March 2014 - 12:42 PM.


#20 RJFerret

RJFerret

    Advanced Member

  • Member
  • PipPipPip
  • 1066 posts

Posted 16 March 2014 - 09:11 PM

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 by RJFerret, 16 March 2014 - 09:13 PM.

"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

#21 AluminumHaste

AluminumHaste

    Darkmod Contributor

  • Development Role
  • PipPipPipPipPip
  • 5886 posts

Posted 16 March 2014 - 11:42 PM

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 :)

I always assumed I'd taste like boot leather.

 

#22 ungoliant

ungoliant

    Advanced Member

  • Member
  • PipPipPip
  • 1747 posts

Posted 17 March 2014 - 03:20 AM

grats on getting this done! dawn of a new DR era!

#23 SteveL

SteveL

    Hero Coder

  • Active Developer
  • PipPipPipPip
  • 3669 posts

Posted 17 March 2014 - 03:23 AM

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!

#24 SteveL

SteveL

    Hero Coder

  • Active Developer
  • PipPipPipPip
  • 3669 posts

Posted 17 March 2014 - 03:39 AM

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 by SteveL, 17 March 2014 - 03:43 AM.


#25 SteveL

SteveL

    Hero Coder

  • Active Developer
  • PipPipPipPip
  • 3669 posts

Posted 21 March 2014 - 06:01 AM

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 by SteveL, 21 March 2014 - 08:28 AM.




Reply to this topic



  


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users