Jump to content
The Dark Mod Forums

Patch splitting in Dark Radiant -- New version 29 Mar


SteveL

Recommended Posts

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

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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
Link to comment
Share on other sites

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

"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

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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
Link to comment
Share on other sites

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
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recent Status Updates

    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
×
×
  • Create New...