Search the Community

Ah, you are right. I was thinking that the TextureMap stores CShaders, but as you say it only stores the Texture objects.

This should not happen, because the checkBindings() just checks the TexturePtr's uniqueness and not the ShaderPtr's (CShader). The checkBindings() is called in the CShader::~CShader destructor and is supposed to remove unused Textures from OpenGL. If the GLTextureManager finds anything unused, it destroys the Texture object, not the Shaders, therefore it should not be fired recursively. Does this actually happen or is this a general question?

Why? I thought the purpose was that we have a high-res repository, that people can use if they want to, and we release with the DDS scaled down textures? Also, wouldn't texture artists create a TGA version anyway? Or do they create DDS directly? I thought that DDS can be created only with a converter.

Just give the light texture lights/ambientlightnfo and you'll get what you want. You can extend its dimensions so it covers entire map or give diffrent ambient lights in diffrent parts of the map.

I was curious and re-enabled the compilation of this ominous TexTool (which was disabled compiler directives) and surprisingly it compiled without complaints. This is what I found: Pretty damn cool, if you ask me. It basically visualises the location of the selected brush face in texture space and allows you to manipulate the thing with mouse clicks (translation/rotation). The behaviour is similar to the UV mapper in blender, but without vertex drag manipulation. And it only works for single brush faces. Judging from the comments in the code, it most probably has some major flaws (being the reason why it was disabled in the first place), but I feel an urge to get that tool working! I put up a new snapshot for this tool so that SneaksieDave can have a look at it too: http://208.49.149.118/TheDarkMod/download/...8.x.rev1004.zip

Oh, I see. I think. No, if you want to actually curve it you will need to use mesh geometry. You could partially fake it using normal maps in certain situations but that might get complicated. Leaves are typically done with alpha maps. You have 1 poly (2 tris) for each leaf, but some texels (texture pixels) are not drawn. If I'm understanding you correctly this won't work for you here.

Yeah, I just checked the texture & it has no alpha so it's in the shader: models/weapons/waterarrow/waterarrow_tip { glass //twoSided noSelfShadow forceShadows deform turbulent sinTable 0.0175 (time*0.5) 10 { //vertexProgram heatHazeWithMask.vfp vertexProgram heatHaze.vfp vertexParm 0 time * 0.3 , time * 0.5 vertexParm 1 1.5 //fragmentProgram heatHazeWithMask.vfp fragmentProgram heatHaze.vfp fragmentMap 0 _currentRender fragmentMap 1 textures/sfx/vp1.tga fragmentMap 2 textures/water_source/vp_water.tga } { blend filter map models/weapons/waterarrow/waterarrow_tip.tga zeroClamp } }I just copied that from one of the water shaders. The rest of the water arrow (& other arrow) textures do have an alpha channel so you can see through parts of the arrow head.

Im probably confusing my terms somewhere, what I want is for the "panels" of hedgerow texture or material to be curved, so I can shape my hedge. But I don't want to use polys, I'm just drawing pixels here, at least I think I am. So can I bend the section of pixels that makes the image, without applying it to a polygon surface? The image of the hedge section I posted, can that , as a pixel map, be curved or warped or something or is it always going to appear as a flat plane? This game ThinkTanks I bought recently, lots of fun, has these toony little trees, but the leaves are pixel maps I think and they are gently curving palm type leaves. If I can do something similar, it will make things look a lot more organic.

Here's one: It would be useful if the S and T fields (whether they wind up on the texture dialog or a separate one) have up/down arrows as well. It's a pain typing 0.03586798 into that box and then adjusting it by hand till you get it just right.

I have merged in the refactor of the model plugin which removes the duplicate PicoModel and PicoSurface classes and replaces them with the RenderablePicoModel/Surface classes which are used by the model preview. This is a work in progress, and there may still be problems with model rendering (I know there is something screwy going on with the texture coordinates in lighting mode).

I assume that this can be done by assimilating the texture coordinates of the shared control points. I'll implement it tomorrow and let you test it, ok?

That's part of what I'm asking - what determines the flip? You said that the texture doesn't shift, so I'm trying to figure out where is it anchored?

I'm really only talking about one thing here that doesn't currently exist, and speaking about a couple of possible bugs (the same that existed with alt-MMB when all of this started). I realize not every case can or should be handled. I'd think aligning texture between two adjacent patches is probably a basic need, just like brushes...? Edit: I'll try to get my post together ASAP, you'll see what I'm talking about.

From the bugtracker notes: SneaksieDave, I get the impression you're getting more and more lost here, which I think is because you want the texture tools do things they're not designed to do. Generally spoken, I don't believe that I will ever be able to cover every kind of texturing situation (virtually impossible). We'd end up with DarkRadiant having 25 different sorts of texturing commands, each working slightly different. I suggest that I will document the implemented features first and explain the background of how they work. Then we can go ahead and do some tutorials or whatever to explain how common texturing situation can be mastered with the given tools. Specialised situations will probably always be up the mapper to tackle, because it is an art after all. If a common problem can be nailed down and reliably described, then I'll happily try to code some algorithm that are able to ease the mapper's pain (if that is possible at all from the coding point of view).

It's similar to that. What happens is the same as when the mapper manually shifts the texture up and down via the patch inspector. It most probably doesn't work when the target patch is moved away from the source patch, because the routine for compensating the 3D distance is not yet implemented, although I already have some approach that I need to test.

Are you able to just get the texture coords at the exact point where one patch ends, and then (regardless of orientation, or position) just start pasting it exactly from that spot on the nearest edge of the second patch? That's what I originally assumed would be the action. Either way, the image above looks great!

You know, looking at these it occurs to me that we really should have a texture webpage just like we do with models. It would be very handy to be able to see all our textures in one spot, and I imagine it would make it a lot more obvious what kinds we are missing. Not only that, but we could see much more clearly which ones are not high enough quality, or whether certain types of textures go well stylistically with others. BT started one, actually, way back when. But we really should do something similar to the models page, where they are organized by category.

Looks good! If I may make a suggestion for future textures... You may be able to improve textures by not having the diffusemap be so independent from the normalmap. (eg, in ornament_006, 007 and 008) Assuming that such protrusions would be made from different blocks of stone, it may be a good idea to have the diffuse texture be discontinuous at the edges of the protrusion. Another possibility would be to consider how water might pour off of large protrusions... You might get stains near some of the edges.

The original hedgerow photograph will have "baked" lighting, so you may need to create the diffuse texture mostly from scratch, yeah. You *can* just use the photo, depending, but it might look bad in some contexts. To test this, try flipping it upside-down. If you can definitely see that the light is coming from below, then you may want to reconsider.

Oh but that's what I mean; even with reclicking the source, I can't get it to copy the coords anymore. But anyway, that's 0.8.1. It's fixed now. I made myself a small list of things to try out with this new one, to be sure I'm not reporting stuff that's been fixed already. Even with that single fix, things already feel better. Ahhhh. Edit: and hooray for Flip X, Flip Y, the very point of this post! Just successfully made a fully continuous ceiling arch with it. Edit: Oh man, this is beautiful. Hours of struggle yesterday trying to get one patch to pick up the same texture alignment as another has been replaced with three clicks: MMB, Shift-MMB, Alt-MMB

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

Thanks New Horizon! @SneaksieDave: This is the result of a single flip operation on a simple brush: You will probably notice that the texture is not perfectly mirrored, as I mentioned above.

-- update priest texture -- create alternate nobleman skin -- try 'blend add' for underwater overlay. Ok, that didn't work either. I officially give up on underwater overlays. (For future reference, blend filter is the 'multiply' equivelant, and would work best for most grime decals)

Well some progress at least -- apparently the Radiant designers decided that GTK Warnings should be raised as fatal assertion failures, which I have corrected. This particular issue now just displays as a warning in the console, but the dialog itself is shown. This now reveals the next problem, a shared_ptr assertion failure when you actually activate the background image. I think this is happening because the first time you enable the option, the image filename is blank which is causing whatever provides the image texture to choke.