Texture Copy/paste

[greebo]

If you figure out a way to handle that, you will have solved one of the biggest and most persistent texturing problems known to man and woman alike.

Done . I wasn't able to commit this during the last weekend, because my DSL went down till today.

 

Basically, it's now possible to seamlessly texture a brush/patch transition, such that the texture is preserved in scale, shift and rotation.

 

So it looks like this (left is the patch with its control vertices, right is the untextured situation):

 

 

One is now able to choose between two texture copy modes: 1) Projected and 2) Natural

 

The result on the left is the projected texture copy (note the distortions on the patch). However, for coplanar patches and inverted end caps this works like a charm. The right image was done with the new command ("PasteTextureNatural") accessible via Ctrl-Alt-Shift-MMB. This virtually "flattens" out the patch and therefore allows undistorted texturing, as the 3D distance between two control vertices is taken to calculate the texture coordinates. The result is undistorted and of course seamless to the adjacent brush.

 

2. The ability to undo transformations. At least I should be able to undo them to the state that existed before I opened up the texture window or before copying a texture's orientation. In D3ed, sometimes I'll work for a half-hour, iteratively rotating, scaling and shifting a texture until it matches a brush... then I'll accidentally middle click another brush or some such, and lose all that work.

I think this already works in DR. At least the above steps are all undoable as far as I know.

[Mr Mike]

This is fantastic, many many thanks Greebo!

 

Now you need to get that background image import working!

[OrbWeaver]

Fantastic. I take it this works OK in the game also?

[angua]

Yes, it does! This makes texturing really fun, and I haven't had any problems with it.

[OrbWeaver]

Can the projection mode also be changed on an existing patch? It might be nice to have extra options in the surface/patch inspector to change the texture projection in this way.

[SneaksieDave]

 

*drops D3Ed* (well... almost )

 

You guys are all over this thing. When's the next build release?

[greebo]

Can the projection mode also be changed on an existing patch? It might be nice to have extra options in the surface/patch inspector to change the texture projection in this way.

No, after the texture coordinates have been calculated, they are "baked" into the patch, there is no meta-information available à la "this patch was textured using brush and scale using face normal vector". However, as the originating brush face is saved in the clipboard, you can check out both results by just using different modifiers (Ctrl-Shift-MMB for projection, Ctrl-Shift-Alt-MMB for natural, by default).

 

*drops D3Ed* (well... almost )

You guys are all over this thing. When's the next build release?

That depends on when we reach the next stable state between the feature implementations. Orbweaver is working on some inspectors at the moment, I don't know how much is still left to code. Perhaps there will be some christmas release?

[OrbWeaver]

No, after the texture coordinates have been calculated, they are "baked" into the patch, there is no meta-information available à la "this patch was textured using <this> brush and <this> scale using <this> face normal vector". However, as the originating brush face is saved in the clipboard, you can check out both results by just using different modifiers (Ctrl-Shift-MMB for projection, Ctrl-Shift-Alt-MMB for natural, by default).

 

Fair enough. If only there was a more intuitive inteface than triple-modifier-clicks -- perhaps I can stick in a dialog or something at some stage (the best solution is probably Blender's little pop-up menus, but those don't exist in GTK as far as I can tell and would probably be more confusing as they are a non-standard idiom).

 

That depends on when we reach the next stable state between the feature implementations. Orbweaver is working on some inspectors at the moment, I don't know how much is still left to code. Perhaps there will be some christmas release?

 

I think we should soon be ready for a 0.8.0, we have some fairly important new features (fixed patch texturing, light inspector, projected light support, draggable light centres, entity chooser hierarchy based on key in DEF file). I have recently started on the generic skin selection dialog, but this could conceivably wait until 0.9.0 (along with at least one of the new Dark-Mod specific editors) depending on how long it takes.

[greebo]

Fair enough. If only there was a more intuitive inteface than triple-modifier-clicks -- perhaps I can stick in a dialog or something at some stage (the best solution is probably Blender's little pop-up menus, but those don't exist in GTK as far as I can tell and would probably be more confusing as they are a non-standard idiom).

At least it's customisable, so the users can choose what mouse buttons and what modifiers they want to use. (Not quite like a pop-up menu, but I don't like those too much anyway...)

 

I think we should soon be ready for a 0.8.0, we have some fairly important new features (fixed patch texturing, light inspector, projected light support, draggable light centres, entity chooser hierarchy based on key in DEF file). I have recently started on the generic skin selection dialog, but this could conceivably wait until 0.9.0 (along with at least one of the new Dark-Mod specific editors) depending on how long it takes.

I'll finish reorganising the brush.h header file, and then I will look into the upgradepaths / xml file handling. Once this is done, I would say this thing is ready for takeoff.

[OrbWeaver]

I just tried this out, and it works like a charm. I think we can simplify the modifiers a bit -- there is nothing else using MMB in the camera view AFAIK so we may as well use something easier to remember. I find MMB for copy, Ctrl-MMB for paste projected and Ctrl-Shift-MMB for paste natural to be quite comfortable, although you may have a better suggestion.

 

One thing I think we should change is patch creation - currently this does not delete the selected brush which I find inconvenient and will probably confuse DoomEdit users.

 

Also, I retract my suggestion that the control system should be inverted so the target patch copies its texture onto the currently-selected patch. The ability to copy a texture once and then rapidly deploy it onto numerous surfaces seems to be advantageous. However we must make sure that the undo support is impeccable in case a user targets the wrong patch -- which I think it is, based on cursory testing (i.e. I tried it once).

[greebo]

I just tried this out, and it works like a charm. I think we can simplify the modifiers a bit -- there is nothing else using MMB in the camera view AFAIK so we may as well use something easier to remember. I find MMB for copy, Ctrl-MMB for paste projected and Ctrl-Shift-MMB for paste natural to be quite comfortable, although you may have a better suggestion.

Perfectly ok with me, feel free to change the default settings in input.xml, mappers will always be able change it to something different.

One thing I think we should change is patch creation - currently this does not delete the selected brush which I find inconvenient and will probably confuse DoomEdit users.

You mean if there is anything selected and the user hits Shift-P the patch gets created and the brush stays there? Should the selection really get deleted on patch creation? I wouldn't like this, so I would make this a configurable option (i.e. registry key value).

 

Also, I retract my suggestion that the control system should be inverted so the target patch copies its texture onto the currently-selected patch. The ability to copy a texture once and then rapidly deploy it onto numerous surfaces seems to be advantageous. However we must make sure that the undo support is impeccable in case a user targets the wrong patch -- which I think it is, based on cursory testing (i.e. I tried it once).

Yes, I like the clipboard idea more than DoomEdit behaviour. If I was to implement D3Ed style texture copy, I would have made it an option, because I find it much less effective.

[greebo]

I've committed the "Paste texture coordinates" methods to SVN. Mappers can now clone texture coordinates from one patch to another patch of the same dimensions (the shader stays untouched):

 

The left patch is the source patch, the right one the target patch (but this can of course be reversed as well). One has to copy the texture from the one patch into the clipboard and paste the coordinates then via Alt-MMB onto arbitrary patches (with matching dimensions).

 

Same as above, but now the shader image is the same for both patches.

[OrbWeaver]

Sounds quite cool to me -- I guess the idea is that you can fit your texture onto a simple undistorted patch, then copy this texture onto an already-distorted patch while keeping the same texture coordinates?

[greebo]

The texture (i.e. shader image) itself on the target stays untouched, it's only the texture coordinates that are being transferred (like in the shots in the first row in my above post). Maybe this comes in handy.

[SneaksieDave]

Is that pinching distortion on the fourth image unavoidable? That happens frequently in D3Ed when texturing such curves. Oddly it doesn't seem to be there in the second image.

[greebo]

I'm sorry? What exactly do you mean? The patch itself is distorted, so the texture will be distorted as well. Or did you mean something different?

[SneaksieDave]

See the way in this image,

there is rippling at the bottom half of the texture? It's easy to see with the carpet lines.

 

However in this one,

there doesn't seem to be the same distortion. Or at least, it's harder to see.

 

Anyway, I guess the point is: if there's no distortion on an un-fitted texture:

then why would a fitted texture necessarily show rippling? It's still ultimately just a texture, fitted, and laid across the same surface as the tiled one. Squeezing of the texture, to make it fit, yes. But the rippling almost suggests an imprecision maybe, or rounding problem? (I might be completely wrong here.)

[OrbWeaver]

The "rippling" happens because the patch is internally subdivided into a series of triangles for rendering, each of which only has three texture coordinates which means the texture cannot "bend" within the space of a single triangle. You could improve the smoothness of the distortion by adding more triangles, but this would obviously have a performance impact.

[SneaksieDave]

Makes sense. So is it just not (as) apparent in the second image?

[OrbWeaver]

Makes sense. So is it just not (as) apparent in the second image?

 

Yes. If you look closely at the lines you can see there is some jaggedness there, but it is not as pronounced since there is no regular grid pattern.