Topic: 3D Modeling WIP Topic

[kat]

To do the opposite you'd have to treat meshes like brush volumes and clearly define segments with their own material/shader assignments otherwise yes, you'll end up adjusting everything at the same time in UEd. In Blender that means cutting the structure up and assigning different Materials to different sections of the mesh (even if they are mapped using the same image); so long as you stick to the power-of-two rule mentioned above that should then mean as you increase/decrease texture scale it should still apply uniformly over surfaces - 1:1 scaled x2 means an even 2:1 assignment because the model is 2m x 2m and so on... (in addition you might need to export to FBX if you're not already as that has better support for multiple-material assignments).

Not sure what's going on the the verts other than you perhaps not selecting/deselecting properly, when you work at a reasonably quick pace that can happen (especially when Blender is being a bit slow to respond). You can toggle grid-snap in Edit Mode using "Shift+Tab". If you have GtkRadiant 1.5 installed you can export brush volumes directly to OBJ (although they are blank iirc), else you can always convert brush structures to models using BSP2ASE (note that to get an ASE models successfully into Blender you have to use Blender 2.49 and the ASE import script, once done open that saved file into a newer version of Blender).

[silicone_milk]

I may have sort of figured a way out without having to apply a unique material to every face.
I can select a face, unwrap just that face, and then scale/rotate/translate as needed across a tiling texture loaded in Blender. Islands may overlap but I'm ok with this.
Comparing the UV layout from manually unwrapping each face individually and just doing a Cube Projection shows that the cube projection method produces nearly identical results. The main difference is that the angled faces are projected (hence the name) to a plane and so their uvs align perfectly with the planar faces. Manually unwrapping has the UV straightened out and running with the direction of the face causing visible seams where it meets a face sitting on an axis.

For example, here's cube projection on the left, and a manual unwrap of the angled face on the right.
The latter would typically not be an issue (and would actually be desirable) because I never usually would tile textures across angled faces like that when mapping for Quake 3. Angled faces were usually a cue to apply a trim texture to separate two axis-aligned surfaces and "hide" the texture seam by avoiding it altogether.

Additionally, I found that I have better results with the cube projection if I enable "scale to bounds" so it uses up all of the texture space for the uv islands. I have a color grid at 4 different resolutions (256x256, 512x512, 1024x1024, and 2048x2048) that I can swap between and it appears to be a lot easier to wrangle with the density issue.

[silicone_milk]

And then there is abandoning the UV layout and using UV coordinates generated from an object + cube projection.
This is generated using object data (linked to an empty) and gives me consistent results across two objects (window and support pillar thing)

For lightmap UVs I could just have UE4 generate them I suppose.

[kat]

If you want to unwrap those inner bevel faces so you can apply a trim texture it's best to map them as a single chain of faces. The optimal way to unwrap and object like that would be to do the following;

1) select all the outer faces of the object and UV unwrap them as a unit.
2) select all the bevel faces and unwrap those as a unit.
3) select all the inner arch faces and unwrap those as a unit.

In each instance ideally you want to use "Unwrap" rather than "Cube Projection"; the former constrains itself to the groups general orientation, the latter doesn't. What this will mean in this instance is that you'll end up with three distinct UV islands in the UV Editor which you can position as needed. If you then want to assign different materials to each group you then just assign a material/texture per group of faces rather than individually (which isn't very efficient) - it's not a good idea to treat models exactly the same way brush volumes are when it comes to texturing.


The specific problem you're having with tiling across units is the result of not fully following power-of-two; although you're using it to define object structure in terms of unit size/dimensions, you're not mapping images edge-to-edge so you end up tiling to a cutoff point that's inside the available texture space instead of the edge/boundary - wherever possible you want to be UV mapping, at least horizontally, edge-to-edge (i.e. 1:1, 2:1 3:1 etc., across the width of the object).

[silicone_milk]

I wanted to avoid unwrapping the UVs in that way (specifically with the beveled edge of the arch) as the seams would be glaringly obvious. I've played with the unwrap a little and have some stretching in the arch but I think it would be acceptable. If I change my mind and decide to have the game be in first-person where the camera can get super close to the texture then I might not be able to get away with it though.

I also created a new cut in the arch where the wood frame is so I can have the main seam land there and be hidden by the frame.



I could possibly use the face that there would be a seam at the beveled edge if I were to unwrap it similar to how you've done it and create some new faces to map the "trim" to (arches need a keystone and support stones).

[kat]

That a better way to unwrap if the seam can be hidden under the Window frame (wasn't clear originally how the section of the mesh was constructed), you will get some stretching (as you note) but it won't be significant.

Re:seams and smoothing: depending on the model format it may be possible to export and set up the mesh in UEd to ignore UV based seams and instead use actual split vertices - not familiar enough with UEd tools to know how that can be done but I know it is possible.

Incidentally if the outer edges of the mesh are just there for front-to-back depth (not seen in-game) you can reduce their respective UV's to a minimal size to free up space they would otherwise being using, making it available for something else. Also make sure your major structure is mapped to the texture edge-to-edge so model units tile properly without texture cutoff.

[silicone_milk]

There originally wasn't a cut hiding behind the woof frame. I only added one to have a place to stick the seam.
The outer faces of the mesh are just there because meshes with holes in them bug me. Years of Radiant editing has me wanting everything to be volumes lol.
I unwrapped them and just let the islands fall wherever since I don't care what's going to be on the face (it won't be visible).
I'll force them to not be overlapped in the secondary lightmap uv channel.

There're are some interesting tools posted over on Quake3World that may be exactly what I've been looking for (Blender plugin) so I'll be playing with that tonight before deciding to just call it good and move on to modeling more assets or not. I gotta say, I was pretty proud after seeing the mesh in-game after the latest UV changes and seeing how well it looked with a third-person camera + character model next to it.
I'm still torn between making the game first person or third person. I may make it primarily third person with an option to zoom in to first person like you'd see with Zelda camera controls (Wind Waker, Ocarina of Time).

Next on my list of stuff to work on are mesh pieces for use in spline modeling inside the UE4 editor. Roads, rivers, trees, fences, clotheslines, and all kinds of pipes and what not would be super easy to throw together using the UE4 splines. From brief play with them about a year ago they were pretty fun and powerful.

[kat]

Not entirely sure those techniques can be used without some modification because they don't UV map elements in a way that's usable in game (the technique works Blender to Unity because Unity is able to parse the *.blend in a usable way, else some additional steps to 'make real' are likely going to be needed); it's projecting image data rather than relying on the presence of a functional UV map, i.e. it's 'generated' data (arbitrary) rather than being 'fixed'. .

iirc UEd prefers 'closed' meshes so unless you have a lot of faces being wasted leave them in, it helps the engine analyses and process the tessellated structure of the mesh.

[silicone_milk]

The UV Project modifier in Blender lets you assign multiple projecting objects and pretty much replicate cube projection. However, once applied, UV islands are created. Islands overlap but it's ok since I'm just tiling a texture across segments of a mesh. The islands can't overlap for the lightmap uv channel though.
Example of the UV Project modifier:

This was prior to scaling the empty projector objects so that the 1024x1024 texture fits (horizontally) to the mesh since a wall of 300 cm in height would use about a 1024 texture based on a dimension-to-pixel guide for UE4 I've been looking at.

[kat]

Ah good, wasn't sure/clear what the modifier did to 'make real' the projection it maps to a mesh - the video linked above made it appear like the objects are left in the raw state, which would mean Unity was able to parse that information (not entirely sure how complex the *.blend importer/loader is for Unity so don't know what it can or cannot use beyond traditional mesh/UV's etc.).

For lightmaps just create a second UV layer and map everything inside bounds (shrink the edges/bits not visible down in size so they don't use up too much space).

[silicone_milk]

Yeah, it's sort of annoying because the UVs don't exist until you apply the modifier. After you apply it, if it turns out to be wrong at all and you want to fix it, you have to reapply the modifier and re-link the 6 projector objects.
I ran into an instance where I decided to just unwrap manually to keep faces contiguous (wood support beam on a window mesh). I realize in hindsight I could have just moved the uv islands together and stitch to save time.
Here's a second window mesh I was working on last night. The first wall mesh was 1 meter thick while normal walls are typically 10-20 cm thick. This is a 20 cm thick wall and the measurements actually worked out quite nice for the thickness of the wood beam on the top (30.99 cm = ~1 foot)

[kat]

If edges/seams where meshes meet is/might be an issue (texture wise that is) you could always create a 'joiner', an object that bridges the join between wall sections/parts; a wood beam, stack of cornerstones, a gutter/down-pipe or similar semi-decorative feature - if you make several slightly different variations it'll limit the degree of part repetition where the trick is used too extensively; two wall sections with four 'joiners' produces quite a long structure.

[kat]

Should probably show what some of that brushwork put together in Blender looks like when exported and built up as a level in Return to Castle Wolfenstein - still undecided about going this route or not as it can't be monetised (uses Bethesda IP obviously), but it'll be a darn site quicker to publish a finished product. RtCW is also limited in terms of using what's available monster-wise (not sure of vanilla RtCW can take more being added), although everything would pretty much be fine.

[ratty redemption]

very cool. i love the atmosphere. that fog effect is excellent. both visually and it really makes you wonder what's in the shadows. perfect for a horror game like rtcw.

i assume they flames are being drawn over the z depth fog? i like how they indicate there is a path in the distance, even though it's obscured by the fog until the player gets nearer.

how's the size of your map compared to the original rtcw maps? it seems a little larger, although i might be remembering the others incorrectly.

also you could finish this rtcw version then port it over to unity in the future. i'm going to be testing code for 1st person cameras soon, and i have a pretty decent player controller script now, just need to add in jump and crouch and it should be close to what you have there with rtcw.

[kat]

Yeah technically light sources in fog become more and more hazy and indistinct with distance, that's hard to do in RtCW with all the issues cause by alpha-sorting. In this instance their not specifically doing that works like you to point out a path even though it can't be seen as you say.

Regarding the size: the section shown is about 1/5th of the entire map (maybe less) and it's already exhibiting lighting artifacts because it contains a lot of detail and surfaces (want to use more models than normal) - light maps are not being properly calculated for light sources so some faces are starting to appear unaffected even when a lamp is right next to them (this doesn't change using later versions of Q3Map2 either). This essentially means to get the entire level to work it will have to be split into about a dozen or more smaller level sections that allow the player to go back and fourth between them (although this can be done in RtCW, because a map is a map is a map, it's unclear if 'state changes', what weapons, achievements etc have been recorded, carry over properly when going back to an area previously explored).

Porting to Unity is possible but it would probably be through the use of a specific version which is being built in Blender - slightly more detailed and uses different textures (obviously).