Jump to content
The Dark Mod Forums

Texture Flip


Recommended Posts

Concerning this issue #82, this is what I could accomplish so far:

 

texturefliplf8.th.jpg

 

It works currently with brushes only, I haven't looked yet at the patch code (this might be more complicated, but I don't know yet). The according GUI elements / buttons are still missing, but this is something related to the new Surface Inspector dialog that should come in the near future.

Link to comment
Share on other sites

The patch flip was easy, because the routine was already an unused member of the Patch class. :)

 

textureflippatcheskl7.th.jpg

 

Right now, this feature is accessible via shortcuts only. I think it is best to wait until the Surface Dialog is overhauled, before the "FlipX" / "FlipY" buttons are added.

Link to comment
Share on other sites

One thing though: with the brush above, it doesn't look mirrored, it looks rotated 180 degrees. Did you maybe hit both FlipX and FlipY to get it like that?

I think that was the case, yes. It's not always possible to exactly mirror the texture, sometimes it gets shifted and I haven't looked too far into this (I just modified the texture transformation matrix to invert the x/y scale). Therefore it may be necessary to adjust the texture by shifting it a bit around (in the Surface Dialog or with the Cursor Keys). Is this acceptable?

Link to comment
Share on other sites

One thing though: with the brush above, it doesn't look mirrored, it looks rotated 180 degrees. Did you maybe hit both FlipX and FlipY to get it like that?

 

Definitely looks like a double flip to me -- 180 degree rotation would make the text readable if you rotate your head, which isn't the case.

Link to comment
Share on other sites

I think that was the case, yes. It's not always possible to exactly mirror the texture, sometimes it gets shifted and I haven't looked too far into this (I just modified the texture transformation matrix to invert the x/y scale). Therefore it may be necessary to adjust the texture by shifting it a bit around (in the Surface Dialog or with the Cursor Keys). Is this acceptable?

Of course! Though it does bring to mind a wish of mine - a way to lift a texture (coords, dimensions, orientation) right off a patch and align them to another patch. Maybe there is a way to do this already, but I never seem to get good results without some by-hand adjustment.

 

Yesterday for instance, I had four opposite corner arches holding up a ceiling. I was able to get the two on one side of the room to texture properly. But no matter what I tried - and I tried every single function I know of - I could not get the other two to texture the same way (basically, lining up with the ceiling without distortion). I eventually (after over half hour!) gave up and said to hell with it, deleted the offending two patches, copied the other two, locked the textures, and rotated them. I simply could not get it to texture correctly.

 

I guess my biggest texturing desires right now (since DR has been satisfying the rest nicely) are:

 

1. "Copy the alignment of this texture on patch A and paste it on patch B - EXACTLY."

2. "Take the texture alignment of adjacent patch A and continue it onto adjacent patch B, so they line up."

 

These might actually be possible, but I haven't had success with it.

 

Edit: I will try to experiment today and see if I can nail down exactly what I'm asking for, and to be sure it isn't already there.

 

@SneaksieDave: This is the result of a single flip operation on a simple brush:

Yep! ^_^

Link to comment
Share on other sites

1 "Copy the alignment of this texture on patch A and paste it on patch B - EXACTLY."

I think you have to elaborate this with pictures, I can't figure out what you mean here.

 

2. "Take the texture alignment of adjacent patch A and continue it onto adjacent patch B, so they line up."

Same here. Do you mean that two adjacent patches (with some of their control points sharing the same point in space) should be made seamlessly textured at the transition?

Link to comment
Share on other sites

I think you have to elaborate this with pictures, I can't figure out what you mean here.

Basically, for two patches, one would be able to say "use a copy of this patch's texture for this other patch." If the patches are the same, the texuring would be exactly the same. If they're different... erm I guess that's an undefined area. Maybe it would just keep wrapping or whatever.

 

I am trying this out this morning, and I'm getting very different results from yesterday, so it is possible that I'm coming across some kind of bug here. See the image below. The idea is to just clone the texture on the right patch straight onto the left patch. There is a definite strange inconsistency here, but there might also be something much deeper (why I was having probs last night).

 

Inconsistency, today: If I MMB the patch on the left, and then shift-MMB the right one, I get a nice cloned texture! Undo. Then, if I MMB the patch on the right, and then shift-MMB the left one, I get the basic texture sizing, but it is rotated by 90 degrees (as in the image). Right there, something is wrong, but I can't imagine what's the cause. The patch on the left was constructed brand new for this test, and not copied from the right. Basically, A to B does not equal B to A.

 

[Edit: let me know if you want the map.]

 

Problem yesterday: worse than this inconsistency (which is happily fixed with a rotate 90 degrees), yesterday, no matter what I did, I simply *could not* get the texture to match that of the right arch. It wasn't user error, because this morning, all I did was MMB and shift-MMB and it's done. Last night I tried everything: natural, shift-MMB, ctrl-MMB, alt-MMB(?), rotations, on each of: using the arch as a source, using the wall as a source, using the ceiling as a source, using the floor as a source. NOTHING worked. Eventually I gave up, deleted the patches, and cloned the ones from the right instead. Done in 3 seconds.

 

So. From those evidences above, I'd put forward there is a definite bug (A->B != B->A), and a possible bigger bug, having to do with patch coords at all. Either something about them needs to be "corrected" by the user hitting some magical combo of manipulations before they'll align properly, or perhaps that rotating patches (which was how I originally got them) screws them up somehow irreparably... I don't know. I'm going to try to reproduce it.

 

Same here. Do you mean that two adjacent patches (with some of their control points sharing the same point in space) should be made seamlessly textured at the transition?

Yep, so if the two arches in the image were touching at the top, to make a fully arched roof for instance, they'd align nicely and since the patch on the left has no distortion (it was created with shift-MMB natural unwrap texture thingy), then neither should the right arch have any distortion. This would be great, because then a simple lifting of the texture from an adjacent brush onto a patch, and then from one patch to the next, would give three aligned surfaces.

post-58-1171295868_thumb.jpg

Link to comment
Share on other sites

Basically, for two patches, one would be able to say "use a copy of this patch's texture for this other patch." If the patches are the same, the texuring would be exactly the same. If they're different... erm I guess that's an undefined area. Maybe it would just keep wrapping or whatever.

Do you intend to copy the texture coordinates only? So that a 3x5 patch could copy its texturing from another 3x5 patch, but the actual geometry of these two is different? If yes, this feature already exists, if not, I still don't get what you mean here. :blush:

 

I am trying this out this morning, and I'm getting very different results from yesterday, so it is possible that I'm coming across some kind of bug here. See the image below. The idea is to just clone the texture on the right patch straight onto the left patch.

I would try to texture the left one (as you did already) and then apply the same shader to the right patch. Then I'd clone the texture coordinates with Alt-MMB to the right one. If it still doesn't fit, we now have the flip texture commands as well. Please give me the map, I'll try to do it if I have some spare time.

 

There is a definite strange inconsistency here, but there might also be something much deeper (why I was having probs last night). Inconsistency, today: If I MMB the patch on the left, and then shift-MMB the right one, I get a nice cloned texture! Undo. Then, if I MMB the patch on the right, and then shift-MMB the left one, I get the basic texture sizing, but it is rotated by 90 degrees (as in the image). Right there, something is wrong, but I can't imagine what's the cause. The patch on the left was constructed brand new for this test, and not copied from the right. Basically, A to B does not equal B to A.

I think I know what you experience here, but I'm not entirely sure. Keep in mind that the Shift-MMB texture pasting does not work for the constellation patch>>patch (you can't project a patch onto another in a straight-forward, well defined way as it is possible with brush face planes). You can do some copying and pasting using brushes as "middlemen", but this really depends on the situation. Please send me the map if you want me to investigate this.

 

Eventually I gave up, deleted the patches, and cloned the ones from the right instead. Done in 3 seconds.

:D Well, where is the point in implementing a feature as substitution for something that's done in 3 secs? Why not do it this way in the first place? :)

Link to comment
Share on other sites

Do you intend to copy the texture coordinates only? So that a 3x5 patch could copy its texturing from another 3x5 patch, but the actual geometry of these two is different? If yes, this feature already exists, if not, I still don't get what you mean here.

I guess so, yes. I wasn't intending the geometry to be different (unless mirrored is considered different, in which case yes), but if it can, all the better. How is that done? I haven't been able to get it to work with ctrl-, shift-, the confusing alt-MMB, or natural actions. :)

 

Here's the map to try to show the one inconsistency I was pointing out. Maybe you'll be able to see something funky about the patch itself (X is actually Y or whatever??). http://208.49.149.118/thedarkmod/maps/2arch.zip

 

Whatever it is, shift-MMB copying from A to B is not the same result as shift-MMB copying from B to A. That doesn't really make sense, unless some hidden value is being preserved for one and not the other (which I guess would be a bug) or somehow coords are swapped and the calculation doesn't take that into account (which I guess would also be a bug). I'm going to keep trying to repro yesterday's result, and if I do, that map should be more useful for the possible other issue.

 

Well, where is the point in implementing a feature as substitution for something that's done in 3 secs? Why not do it this way in the first place?

Yes, I know. :) But, I meant in the more general sense. If the user wanted a way to clone a texture alignment from one patch onto another, they couldn't. Those patches might not be identical, making the cloning useless.

Link to comment
Share on other sites

Hold on, I think a light just went on.

 

Is it possible, at all, to use ctrl-MMB or shift-MMB to copy a texture from one patch to another? Am I correct in guessing that only alt-MMB operates from patch to patch? Ctrl- and Shift- only affect coords... or... um. I don't know what ctrl- and shift- do now.

 

I'm completely freaking lost. I think there's also a distinction I'm not considering, between "applying a texture" and "applying coordinates."

 

Somehow, I've got it so ctrl and shift-MMB do *nothing* from patch B to A, but at the same time, alt-MMB from B to A will give a stretchy undesirable effect, but alt-MMB from a perpendicular patch(!) gives the desired perfect result.

 

What? :wacko:

 

Edit: I really don't get this. I have one set of arches from the map above which fully affect each other with MMB clicks. Now a different set I made, to test alt-MMB texturing, was working great. Then, I cloned the texture from the ceiling. Now, nothing - not ctrl-, not shift-, not alt- - does anything. No effect anymore. Are these problems or am I just losing my mind/don't know how it works?

Link to comment
Share on other sites

Is it possible, at all, to use ctrl-MMB or shift-MMB to copy a texture from one patch to another?

No. You can only copy the texture "name" from patch to patch, as far as I remember it.

 

Am I correct in guessing that only alt-MMB operates from patch to patch?

Yes. Alt-MMB cycles through the control vertices of the one patch and clones the texture coordinates to the according vertices of the other patch. This naturally works only with patches of equal dimensions.

 

Ctrl- and Shift- only affect coords... or... um. I don't know what ctrl- and shift- do now. I'm completely freaking lost. I think there's also a distinction I'm not considering, between "applying a texture" and "applying coordinates."

I think I should write some documentation with some examples, as this appears to be confusing. :)

 

EDIT:

Are these problems or am I just losing my mind/don't know how it works?

If it's reproducible, then it may be a problem, otherwise I just can't know.

Link to comment
Share on other sites

Okay, I've got some quick results here. http://208.49.149.118/thedarkmod/maps/4arch.zip

 

I didn't get into exhaustive case testing yet, because at this point it doesn't seem necessary; something is weird. I know that perhaps shift and ctrl-MMB aren't supported for patch copying, but they do work, and do something, so people will invariably use them and believe they're supposed to. Besides, sometimes you get great results! ^_^ I'll refer to the patches as if they were numbered top to bottom, from left to right (as if the two ceilings are pages of a book).

 

Very simply: load up the map and MMB patch #2, and then shift-MMB patch #3. Note the results, close the map without saving. Reopen the map and do the same thing. I get one of three different results each time.

 

1. Unknown alignment - it's not natural, but it's not scaled to be matched to ceiling or patch

2. Unknown alignment - not natural, not cloned from anywhere - undefined maybe?

3. Apparently natural unrolled from the ceiling. Good, this was the desired orientation (needs a quick 90 degree turn fix). This makes some sense, because patch #2 was created from the ceiling originally, so I guess it is passing its alignment onto #3.

 

But why the other two random behaviors? Is the alignment undefined unless the user takes some known, expected action?

 

Here is the same test run with ctrl-MMB:

 

1. Looks like projected, from the ceiling? I think this makes some sense, as the third result from above.

2. However, what is this?

 

Again, that's just from reloading the map and doing the same exact action again. Something undefined? Sometimes it gives good results, and other times unexpected ones. Sometimes when it's not acting as desired, you can reload the map and it suddenly works.

 

Finally, a couple of results with alt-MMB:

1. Nothing - I got no result. I'm not sure I understand this command, but sometimes, I just MMB a patch and then alt-MMB all over the place and nothing happens anywhere.

2. This appears to be natural alignment (note the stretching), although I'm not sure why that is the result, considering the source.

 

So, if I understand alt-MMB, that one at least might have an actual bug.

 

To repeat, this is not an exhaustive set of test cases, but perhaps enough to get us started looking at this. Yeah these aren't patch modes, but they do give results most of the time. And, even if they're not, they should be (if possible), because they're very useful. I think what's at play here is a few possible bugs and a lot of user confusion (I'm not sure of the proportions though, could be 10%-90% ^_^). The differences between placing a texture, and copying a texture, and copying coords. Looking forward to your examples; it might clear a lot of this up.

 

To roll the wishes into it,

 

1. the ability to reliably take the texture from #2 and put it in exactly the same dimensions onto #3 (I assumed this was meant for alt-MMB, but it didn't work),

2. the ability to 'continue' the texture from one patch onto another as if they were aligned neighbors (even if they're not)

 

Perhaps if those things are implemented, then all of the above is irrelevant, because an undefined action from patch->patch is replaced by a couple of defined ones.

 

:wacko:

Link to comment
Share on other sites

greebo: check this one out!

 

http://208.49.149.118/thedarkmod/maps/5arch.zip

 

The curvature on those patches results from a normal flat brush texture (shift-MMB). If I drag the ceiling brush larger, the curvature goes away next time the texture is applied. Some kind of math problem?

 

http://img463.imageshack.us/my.php?image=flatwarpuz4.jpg

 

Edit: here's another weird one. All four of these patches are textured exactly the same: with shift-MMB copied from the ceiling. However, one of the four (the one all the way to the right) is twisted, and I can't think of a reason why. This was after completely restarting DR.

 

http://208.49.149.118/thedarkmod/maps/6arch.zip

Link to comment
Share on other sites

First of all, thanks for testing, SneaksieDave, this is appreciated. :)

 

I think most part of the undefined behaviour can be explained easily: if you click on any brush during DarkRadiant runtime, the Face you clicked on is remembered (in some sort of "Texture Clipboard"). I just checked in the code and discovered, that the face is even remembered if you load an entirely new map (resulting in a nice crash if you try to paste the texture onto a patch ;-)).

 

I will fix this and I believe we have to postpone further testing, as most of the weird stuff will presumably be gone after my changes.

 

SneaksieDave, would you be willing to setup a DarkRadiant compile environment so that you can compile directly from source? This way you wouldn't have to wait till the next release and we could carry on testing.

 

Additionally, I will have to take care that users get more feedback than they currently do, as everything else is inferior design, I have to admit.

Link to comment
Share on other sites

greebo: check this one out!

The curvature on those patches results from a normal flat brush texture (shift-MMB). If I drag the ceiling brush larger, the curvature goes away next time the texture is applied. Some kind of math problem?

This can be explained by the way the Shift-MMB searches for nearby brush winding vertices to retrieve the texture coordinates from that point. I already explained that behaviour with a picture in another post, I'm pretty sure this applies here as well?

Link to comment
Share on other sites

the face is even remembered if you load an entirely new map

Okay that probably explains much. Make sure to see my previous post and edit (we're posting at the same time ;)) where I indicate some possible real issue with the Shift-MMB from a brush mode. That and the alt-mmb acting wonky above it might be the only 'real' (or at least serious) bugs I guess.

 

I'd definitely like to be able to compile, assuming it's not some giant ordeal... Please say there's some tiny command line compiler and I can use WinCVS to get the source? :) I don't have any microsoft compilers installed on this system and would not like to (although, I suppose I could see about putting it on my work/test machine).

 

Edit:

This can be explained by the way the Shift-MMB searches for nearby brush winding vertices to retrieve the texture coordinates from that point. I already explained that behaviour with a picture in another post, I'm pretty sure this applies here as well?

I remember that post; it was about seeking a corner, right? Will that cause the texture to warp if the source brush is small, but not if the brush is large? Anyway to get around that programmatically? (the mapper could just oversize the brush, clone the texture, and then downsize the brush again). The second issue in the edit might be the same, but it's almost certainly more serious in result, and I'm not sure how a mapper could fix that.

 

Edit: workaround: user can make a cut in the brush at the patch edge and texture it again to fix the warp.

Link to comment
Share on other sites

Take a look here: http://www.thirdfilms.com/darkwiki/index.p...mpilation_Guide. I mocked up a quick guide for compiling DarkRadiant under Windows (although there might be something missing, so your feedback would be more than welcome). Please have a look at it and tell me if you would be willing to go through it or not. You'd have to use TortoiseSVN (which is very similar to use as the CVS tools but behave better :))

 

Once installed, a simple scons is sufficient for a recompile.

 

I remember that post; it was about seeking a corner, right? Will that cause the wrapping to warp if the source brush is small, but not if the brush is large? Anyway to get around that programmatically? (the mapper could just oversize the brush, clone the texture, and then downsize the brush again).

I'll have to look at it, but I will first deal with the other thing. :)

Link to comment
Share on other sites

Egads, yeah that'd definitely be something for my alternate machine. Will have to look into that. Is it possible to do automated drops (zips) after each build, or is that not practical? Something not public, so that you wouldn't have to worry about everyone using an interim build. It'd save me having to enter that world again... *shiver* Well, either way.

 

Sorry for dumping all this chaos here... I'm probably one step away from a headache myself, trying to keep all of this straight in my mind. Issue? Not an issue? User error? Who knows. :) Maybe I'll step off and await the examples to at least avoid me doing things incorrectly. I'm learning some ways around problems from all of this, which might mean I'm learning the correct ways. That'll help to report any actual bugs, more efficiently.

Link to comment
Share on other sites

This idea is not bad, I could upload some sort of "nightly" build to the FTP, and I think I can do this right now as well so that you can test the changes.

 

I will just zip the darkradiant.exe, the dlls and the xml settings, you'll have to unpack it over your existing installation, so you might want to install a DarkRadiant 0.8.1 release to a separate folder for this purpose.

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

    • Ansome

      Finally got my PC back from the shop after my SSD got corrupted a week ago and damaged my motherboard. Scary stuff, but thank goodness it happened right after two months of FM development instead of wiping all my work before I could release it. New SSD, repaired Motherboard and BIOS, and we're ready to start working on my second FM with some added version control in the cloud just to be safe!
      · 0 replies
    • 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
×
×
  • Create New...