Topic: Is projection painting available in Blender 2.5?

[Wolfsong]

I've looked through the 2.5 interface and have searched all over google, YT, etc to find this info for myself, but no dice. Check out this video, specifically the actual 3D texture painting part later in the video (the earlier GIMP portion isn't relevant).

http://www.youtube.com/watch?v=r_kO5yPBQos

Basically, I think the way this person is painting their terrain could be very useful in texturing my 3D tiles... However (of course) the tutorial refers to the 2.4x series of Blender, and not 2.5. Any searches I've done only bring up 2.4x tutorials for texture painting.

So I figure I'd ask here to see if maybe someone here could help out with finding it. If not, I think I'll just go back to 2.49. Frankly, 2.5 and the changes they're making between versions is proving to be more annoying than anything else, IMO.

[EDIT] changed the topic heading for clarity. Cheers. >kat<

[silicone_milk]

I'm not sure what exactly you're referring to, but texture painting in 2.5 is certainly possible. In fact, it seems to me that it's much more powerful than the version available in 2.4x

First, make sure you UV Unwrap the mesh for the texture to have a way to be applied to your model.

Then, in the drop down menu that has "Object Mode" and "Edit Mode" there's a few other options. One of them is "Texture Paint". Click it.

On the left hand side of the workspace, if you have default configuration settings for Blender 2.5x, you'll be presented with a color wheel and a series of different menu options. One of these is Texture. Open it up and you'll see a checkerboard pattern because there's no texture applied to your paintbrush yet.

You'll have to make a new texture as you normally would if you wanted to apply it to a mesh, then select it as your texture in the Texture Paint's Texture menu.

One of the things to pay attention to is the Project Paint checkbox in Texture Paint's settings menu. With this checked, the texture you have selected is going to be applied perpendicular from the camera's facing position. I haven't figured out how to properly use it to prevent texture stretching on surfaces curving away from the camera yet.

Another interesting feature is the Quick Edit button in Texture Paint's settings menu that will open up the image editor of your choice if you've set one in your User Preferences and lets you draw directly on the mesh from your camera's last point of view. When you're done, you can save, exit the program which brings you back to Blender, then click Apply to see your model automatically update with the new texture info. Pretty neat tool.

[Wolfsong]

I guess I should have been more specific.... :-p My bad.

I'm referring to how he uses that "clone" tool to copy directly from a texture map..

Been trying to find that tool in documentation and in the program, etc... Is it still possible to use that specific technique?

I like that particular approach because it would allow me to maintain the same UV coordinates from one model to the next, so they would (theoretically) line up properly and you wouldn't see any seam-lines where the texture ends on one tile and continues on the next.

I like how it gets the same results as using GLSL blending, but that you're painting the actual physical texture and not using a technique that's specific to Blender. In fact, I think he says in the video that they added that capability specifically for people who don't have GLSL support and can't use that method.

[kat]

Yes there is, and yes, the current docs are woefully out of date. The only vid I've found which mentions the clone paint feature is Messers Williamson and his making a concrete barrier. It's a vimeo vid so you have to pretty much let the entire video load before you can watch the bit you want, which is about 22 minutes in (the entire vid is about 1hr).

Quick rundown, select your textured object and go into "Texture Paint" mode (make sure you can see your textures - "Alt+Z" to switch to "Textured" view). In the "Brush" section (ToolShelf should be open - "T"), click the thumbnail to view the brush options. Click "F Clone". To paint, hold "Ctrl" and LMB click anywhere in the texture to select a 'clone' area, then just paint - that last one is important because you can't choose or set a clone selection using normal mouse clicks so nothing will happen.

[Wolfsong]

Ahhh nice. Thank you very much for that.

lol the ubiquitous barrier video. I was searching through Blender Cookie for some tutorials between yesterday and today and found it funny that that tutorial is categorized under almost every category in their tutorials list it seems. Though, I guess since texturing is a fundamental part of any project, it makes sense.

Of course, I didn't think to check it out. Natch.

Let's see how this goes. I really hope this works out as I'm thinking it will. That'll be a major milestone crossed for me, as how to handle the texturing across 3D tiles in a way that's not specific to Blender is the one thing I was still trying to find a good solution for.

[Wolfsong]

Okay, just watched both videos.

The cloning he's using there isn't really the same as what is done in the other video I linked.

The cloning he's using in the barrier vids is a lot like PS's rubber stamp tool, where you sample an area and then PS uses that location as the "source" for the stamping process...

In the video I linked, he uses an entire texture layer as the source for the cloning.  It seems to be based on a much more 1-to-1 relationship between the source layer and the painting layer, carrying over the UV mapping and all. It's actually very similar in effect to using the GLSL method, only it's copying/cloning the texture into place, rather than painting on a stencil map.

I'm not entirely sure the method used in the barrier video would work to the same effect as what I'm getting at. Though, I'm going to check out the other video he references and see if maybe that one addresses more what I'm after. There's gotta be a way to do the same thing in 2.5. I can't believe they'd remove that, considering they'd just added it in for 2.49.

Thanks!

[kat]

Hmm, re-watched the vid. What he's doing there is basically a form of "stencil" painting, unfortunately I don't know if that's available in 2.5 (I've not seen anyone use it). If you can do it you'll probably be able to save the painted image but you'll have issues with pixelation as it'll likely be saved at the size of the original UVW mapping. Doing your terrain this way would also mean having a lot of unique textures to deal with if you want to use them.

[Wolfsong]

Hmm, re-watched the vid. What he's doing there is basically a form of "stencil" painting, unfortunately I don't know if that's available in 2.5 (I've not seen anyone use it). If you can do it you'll probably be able to save the painted image but you'll have issues with pixelation as it'll likely be saved at the size of the original UVW mapping. Doing your terrain this way would also mean having a lot of unique textures to deal with if you want to use them.

Yeah I was concerned about the individual textures adding up as well, with multiple tiles.

The ideal situation would be to have the ability to save models with the geometry, UV and perhaps stencil data packaged with each, and then have each load in external textures. In that case, I'd only need one instance of each texture, and they'd be shared/used by all models using them.

Though then, again... I don't know of any engine that allows that (that I would realistically be able to afford/use).

There has to be a possible way to achieve that, though. There are numerous games that use that method of environment design... FFXI as I've mentioned, all the Dungeon Siege Games. I know Neverwinter Nights 1 does. Neverwinter Nights 2 does for interior areas.

Perhaps this is why I've had such trouble finding resources on how to achieve it... Not many know how.

Hmm... I'll have to keep searching.

[kat]

Most terrain engines use some form of 'stencil' and/or vertex painting to blend textures and/or create feature areas, but... those are specifically tooled for the job. What you might find is these maps are overlays; a map is build and then some sort of tool is used by the level designer to 'paint' over the entire level to give it 'uniqueness' that can be baked or saved as a 'map' the engine can read and interpret.

This is what was implied with the initial question about what engine you're going to be using, it's critically important, so ideally you really need to lock that down otherwise you're potentially doing a lot of work that's not going to be of any use. So... choose an engine, study what you can do with it and then go from there - build around your tech rather then the other way around.. it's much easier.

[Wolfsong]

Most terrain engines use some form of 'stencil' and/or vertex painting to blend textures and/or create feature areas, but... those are specifically tooled for the job. What you might find is these maps are overlays; a map is build and then some sort of tool is used by the level designer to 'paint' over the entire level to give it 'uniqueness' that can be baked or saved as a 'map' the engine can read and interpret.

This is what was implied with the initial question about what engine you're going to be using, it's critically important, so ideally you really need to lock that down otherwise you're potentially doing a lot of work that's not going to be of any use. So... choose an engine, study what you can do with it and then go from there - build around your tech rather then the other way around.. it's much easier.

Sounds like you're talking about height-mapped terrain?

I'm not a fan of that method, crazy as that might sound.

Too restricted (voxel editing notwithstanding; not a fan of that either) and the results never look "authentic" to me. There's the texture stretching on steep/high vertical surfaces. Using an engine that allows mapping on vertical surfaces (Turbine's engine, NeoAxis Engine, etc) has the tendency of showing streaks where a texture mapped along one axis "bleeds" over into a perpendicular surface.  There's the inability to achieve subtle detail and control - without modeling something and dropping it on the terrain, which leads me to my main issue.

The results always betray the fact that it's a bunch of pre-modeled props set on a separate ground plane and you can clearly see a seam where the two intersect.  I have never been a fan of that method. The only games I can think of where they do a good job with it is Fallout 3, Oblivion and some maps in Unreal Tournament 2004 and UT3. It just always has the effect on me that I'm in a paper-thin world of props and set pieces.

That's why I'm going with a purely 3D modeled tile approach. Everything blends together smoothly. Ground can blend smoothly into a cliff, both in geometry and in texture blending... You can achieve small details, like small ridges or cracks in the ground, ridges, overhangs.. You can have things like natural stone arcs transition smoothly from the surrounding ground rather than being obvious separate props dropped in place. And so on. It makes the environments look and "feel" much more solid, I find.

There are benefits to editing with that approach too. Say you're working on a large area on a height-mapped terrain and a decision is made to completely scrap the current layout and re-do it. Now you have to go back, erase everything, re-create the topology and all its nuances/details. You have to re-do the texturing, etc. etc. That can take days, easily, to re-do.

With a tile-based approach, you remove the "offending" tiles, and re-place them with new ones, arranged in the desired layout. Getting the base layout in place with tiles could take, maybe, hours to do... unless there's custom tiles to be created for the new layout. Otherwise, everything just "snaps" into place. Tiling allows you to iterate much more efficiently, and with much quicker feedback on the results.

Here's a great example that actually demonstrates the effect of both approaches as I describe...

Check out this image. It's from FFXI, in an area called Mt. Zhayolm.

Look at the cliffs to the left leading down to the water, the larger rock outcrop to the rear-right, and the small, sharp rise in the ground in the foreground. Notice how that all blends in smoothly? There's no harsh seams. That's because it's all modeled and textured as a single model.

Now, in that same scene, you can see what I'm talking about with props as well. That small mound in the center of the image... You can tell just by looking at it that it's not a solid part of the environment, but a prop dropped on to it, because there's a clear and very obvious seam where it meets the ground beneath it. In a typical height-mapped terrain system, you'd see those seams for everything in that picture. At some point, for the cliffs leading to the water, that would have to be modeled as a separate "prop" and dropped on the terrain, leaving a very clear seam line where the cliff/prop and heightmap terrain meet... Chances are the textures wouldn't mesh or line up properly either.  It's just an eyesore to me.

Incidentally... I noticed something kinda funny in that pic. Look down the shoreline, and you'll notice that same structure used 3 times. I guess they didn't utilize as much variety in that particular structure.  Since the geography adjacent to the shoreline is different as it goes down the shore, the tile borders are probably somewhere right in line with where the screenshot is taken from.

Man I love dissecting this stuff lol.

So... in a nutshell, that's why I'm going with a tile-based approach.

That said, I've decided to revert back to 2.49b for my tile work. I'm gonna wait 'til 2.5 goes "final" and they're done screwing with the interface and deciding what and what not to include. I'm trying to follow tutorials and am finding that too much isn't where the tutorials say it should be. They refer to add-ons that are supposed to be included in the build (according to the tutorial), but aren't. Seems like they change things up from one version to the next, and it's just too much hassle trying to make heads or tails of it. I just want to get my tiles created so I can start testing them out.

So... I'll stick with the stable familiarity of 2.49 for now.

Anyhoo... Off to work!

[kat]

Although 'stencils' and 'overlays' are typically used in heightmap based terrain, that's only because that's pretty much the only 'cheap' way to make a terrain in game and why it's used so extensively, anything else is just far too 'expensive' to implement (see further comments below).

Looking at the screen shot you linked to, I'd say the terrain is based on a simple heightmap deformation of a mesh (in 3D Studio Max or whatever 3D application they used for the asset), there's nothing present in the *structure* to suggest anything to the contrary really as the features of the landscape are all pretty much Z-axis adjustments.

The blending could be the result of either good UVW maps and/or good texture blending, neither of which is mutually inclusive or exclusive - you can get that result with or without either component and not necessary exclusively to a modelled mesh either. You will have noticed as well that the entire scape appears to be textured using the same limited palette, just two textures for the most part. So irrespective of the underlying structure they're still deliberately limiting the resources to make the game run in a manageable fashion (even if the terrain were uniquely modelled). This is actually a key and critical component of the decision making process, and again why it's important to pick and engine first (unless you're coding your own).

You mention Fallout/Oblivion/UT above, they're all games that make extensive use of heightmap based terrain (and 3D assets to disguise the result where appropriate). However, they have relatively complex terrain editors that allow the user to generate some pretty complex texture mixes. But it's still heightmapped - z-axis adjustments.

As of right now there's only one technology (that I know of) that can do what you're thinking to any degree and that's idTech's MegaTexture. This allows the user to model a mesh (any way they please) and then paint that 'uniquely' in the editing tools with textures that are then 'baked' out as a single unique 'map'. The downside is the end result, it's a massive file, hundreds of megabytes. And that's your main problem with doing anything with any form of 'baked' (included) uniqueness; it uses a lot of file space.

Incidentally you wont get any argument from me not to do what you're thinking, but it is advisable to think about it within the context of the technology limitations you have at hand. Building a terrain from modelled sections is all-well-and-good only if the engine has a way of dealing with the poly-count. In other words, if you're building a world using models instead of a terrain made in an editor (you're swapping out the terrain for models), you have to think about how the game treats inbuilt terrain versus models because they're not the same thing - terrain engines typically have some **** mesh optimisation built into them that may not translate that well to model culling techniques.

So again, this is why it's critical to nail down what game engine you're going to use and then work within the context of that. I can't really say much more than that I'm afraid; if you're wondering how certain engines do "X", "Y" or "Z", then that's a slightly different discussion compared to how you would do it in your own project 

Oh almost forgot... those 'dropped on' assets are usually more noticeable not because of texture mixes, but as a result of mesh smoothing differences. If you look at the scene again, you note that the ground has a 'bright' smoothing angle (it's well lit), whereas the bottom half of the dropped mesh has a dark one (probably because they've not split the groups properly). So there again you see, you have another problem to think about, smooth groups over several terrain sections, get that wrong and it won't matter how your textures are blended!

[Wolfsong]

Looking at the screen shot you linked to, I'd say the terrain is based on a simple heightmap deformation of a mesh (in 3D Studio Max or whatever 3D application they used for the asset), there's nothing present in the *structure* to suggest anything to the contrary really as the features of the landscape are all pretty much Z-axis adjustments.

Well, that's only a single screenshot. I chose that shot because it was a quick and easy example of the overall technique.

I can say for certain, it's not a basic heightmap system with z-axis manipulation. For one, on a heightmap, you cannot get 90 degree, perfectly vertical surfaces, there's always going to be a slight slope in there between each vertex on the terrain mesh. The points in the heightmap cannot be moved horizontally (along x or y if z is up). A portion of the cliff in that shot is at *least* perfectly vertical, if not silghtly leaning outward, in which case it's creating a concave angle, something else a traditional height-map can not do.

I could take the time and go in-game to take screenshots of specific locations that really demonstrate this if it would be helpful in illustrating what I'm getting at. There are actual overhangs, tunnels, tiny cracks and crevasses in the ground, etc... and they all blend perfectly smoothly into the terrain surrounding them. There is no seam line where one meets the other. It's seamless in all cases. I have never, in any game or game engine I've ever used (especially from the time frame XI was developed in, ~2000-2002) with heightmap tech that could seamlessly achieve what they do in that game.

Also, understand that while you have a screenshot to look at, I've basically "lived" in the world for ~7 years, and have passed through, looked at and analyzed these environments more times than I can even begin to count.

Suffice to say, they are definitely not using height-maps in FFXI. Further, there is very little - pretty much zero - doubt that they are using tiles. They use a similar technique in FFXIV where it's *very* obvious because they do it on such a large scale and with very distinct and recognizable geometry being re-used, sometimes in close proximity to each other.

The blending could be the result of either good UVW maps and/or good texture blending, neither of which is mutually inclusive or exclusive - you can get that result with or without either component and not necessary exclusively to a modelled mesh either. You will have noticed as well that the entire scape appears to be textured using the same limited palette, just two textures for the most part. So irrespective of the underlying structure they're still deliberately limiting the resources to make the game run in a manageable fashion (even if the terrain were uniquely modelled). This is actually a key and critical component of the decision making process, and again why it's important to pick and engine first (unless you're coding your own)

All the environments in XI are limited to between about 2-4 textures, due to hardware restrictions at the time, specifically on the PS2 which the game was originally built around. Its PC counter-part is basically running on a "PS2 Emulator", for all intents and purposes, and there are various quirks in the way the game is configured that reflects that.

You mention Fallout/Oblivion/UT above, they're all games that make extensive use of heightmap based terrain (and 3D assets to disguise the result where appropriate). However, they have relatively complex terrain editors that allow the user to generate some pretty complex texture mixes. But it's still heightmapped - z-axis adjustments.

Indeed... but it's still based around height-maps and 3D props placed on top of it. The obvious seam where one meets the other, and how they seldom "mesh" well texture-wise is one thing that really turns me off to using them.

As of right now there's only one technology (that I know of) that can do what you're thinking to any degree and that's idTech's MegaTexture. This allows the user to model a mesh (any way they please) and then paint that 'uniquely' in the editing tools with textures that are then 'baked' out as a single unique 'map'. The downside is the end result, it's a massive file, hundreds of megabytes. And that's your main problem with doing anything with any form of 'baked' (included) uniqueness; it uses a lot of file space.

Not at all. That would be to say that the Dungeon Siege games, all based on pre-modeled 3D tiles would require mega-texture tech. Or that Neverwinter Nights 1 would require that. Or that any other game based on 3D tiled geometry would. Or FFXI. Or FFXIV.

It is definitely possible and do-able.

I understand and appreciate your conclusion. However, it seems to be based on the assumption that FFXI's maps are made up of heightmaps with z-axis only modification. Again, that's not the case.

Incidentally you wont get any argument from me not to do what you're thinking, but it is advisable to think about it within the context of the technology limitations you have at hand. Building a terrain from modelled sections is all-well-and-good only if the engine has a way of dealing with the poly-count. In other words, if you're building a world using models instead of a terrain made in an editor (you're swapping out the terrain for models), you have to think about how the game treats inbuilt terrain versus models because they're not the same thing - terrain engines typically have some **** mesh optimisation built into them that may not translate that well to model culling techniques.

Oh almost forgot... those 'dropped on' assets are usually more noticeable not because of texture mixes, but as a result of mesh smoothing differences. If you look at the scene again, you note that the ground has a 'bright' smoothing angle (it's well lit), whereas the bottom half of the dropped mesh has a dark one (probably because they've not split the groups properly). So there again you see, you have another problem to think about, smooth groups over several terrain sections, get that wrong and it won't matter how your textures are blended!

Not really. Again, you're basing that conclusion on a single screen-shot. The lighting definitely helps. No question. However, you also can see a clear seam-line where the texture on the ground intersects the texture on a cliff wall, etc... You can tell where props are because they do not mesh smoothly into each other.  Even with completely flat lighting and no shadows, I could tell the difference.

If I come across as somewhat "snarky".. I don't mean to. I just want to emphasize that my conclusion about how FFXI handles its environments is not really in contention here. It's clearly tile-based. No question.


Anyhoo... lunch break is over. Back to work!

[kat]

If you're asking "how can I build a terrain that looks good", you've got much of what you need above. If you're asking "how did they do that", then that's another question and discussion entirely. If FF takes your fancy then you need to dig into the code to find out what they did, have you actually looked at the assets in 3D Studio Max or whatever it was they used and not just wandered around the game? If not, it's simply observational speculation (because there are dozens of ways to do certain things) that doesn't help you answer your specific problem; how are you going to do it.

The point is... without choosing an engine this is all merely a sophistic and academic discussion. So "yes" you can model your terrain any way you like, "yes" you can texture it uniquely or not, and "yes" to whatever abstract process one might want to add during or after the fact. But... and this is the central point you're dancing around... without choosing an engine you are not actually getting anywhere with it. Choose your tech then work to it's limitations.

[ratty redemption]

i might be wrong but it sounds like the technique wolfsong was talking about is what some people call 'projection painting' here is a youtube search on the subject, seems to cover both 2.4x and 2.5x

http://www.youtube.com/results?search_query=blender+3d+projection+painting&aq=f

personally i'm sticking with 2.49b for the time being as i don't have time yet to learn the new interface, but i would be interested to hear what you guys think of the 2.5x implemention of this?

[kat]

Yep that's it. Looks like it has had a massive make over. Doesn't look as if it can be used over several meshes in one go though (everyone seems to be doing heads with it!) so it might mean having to duplicate and join a set together beforehand, that will then just automatically overwrite any texture assignments.