/3/ - 3DCG

You don't need UVs if you just applying tileable textures to faces.
If you want to see modern programs that work the same, see SketchUp or Twinmotion.
Both can use UVs of course but default is just applying tileable textures to faces.

>>694636
Just select a polygon and hit U->Unwrap, you imbecil.

>>694644
What exactly are they doing to make that possible, though? What calculations are involved? I can try to implement it myself.
>>694646
I understand what UV unwrapping is, I just don't like doing it (same as everyone, really). A naive unwrap doesn't allow me to just
>pick texture
>click polygon
>it magically works with no adjustment required
>correct scale, tiles with neighbours, etc

>>694652
Go play with SketchUp, unironically

>>694652
>>694636
works the exact same in a 3D program. say you have a massive aircraft that you want to apply a tiling riveted metal texture to. you just select a bunch of faces along the body, unwrap them and make the necessary adjustments in the UV editor. so yes, it technically requires unwrapping but you don't need to put any thought into the UV layout.

>>694654
I might not be expressing myself clearly.
I know there are other tools out there that do this. Sketchup (from what I remember) does it perfectly, yes.
I know exactly how unwrapping usually works.
What I want to know is how these tools calculate their UVs, such that I might attempt to implement said system myself in a generalist 3D package.
>>694655
>works the exact same in a 3D program
It does not. What you describe is not remotely the same as what I want.
Consider pic related. I want to be able to click on a "brick" texture somewhere, and then click on rect 1. The texture should be assigned to the quad at an appropriate scale. I then want to click on rect 2 and have the brick texture seamlessly continue. I then want to continue adding to and modifying the geometry without having to worry about what is happening to those UVs.

The above is possible in sketchup. It was possible in ancient game modding tools. I'm sure it's terribly inefficient and awful practice for any number of reasons, but it's possible. I wish to programmatically implement such a system. Does anyone have any insight into how it might be done?

>>694660
what the fuck is appropriate scale? you have to adjust the scale manually regardless because the program doesn't know your intentions. better stick to map editors and ketchup

>>694661
I just mean that it should default to an appropriate scale assuming the model has been built to real-world measurements (e.g. 1 unit = 1 metre). So if I apply a tiling brick texture to a 1x1 metre polygon, it should look correct rather than having tiny/huge bricks.

>>694662
Program Houdini to project all faces individually and scale them to real-world units based on their surface area and texture dimensions. The UV space is your oyster now.

>>694636

Uvs are hardly that much of a chore. You should be building the world from prefabs and not randomly placed shit anyway.

>>694665
OK, there's an idea, thanks. I imagine the various 90s/early 2000s era engines that did this would use a more optimised approach, though- maybe they did something like what you describe while editing then automatically packed the level into one unwrapped mesh at build.
>>694666
I'm fine with the "randomly placed shit" aesthetic in this case

>>694660
>What I want to know is how these tools calculate their UVs, such that I might attempt to implement said system myself in a generalist 3D package.
What do you even mean? The UVs are literally just two coordinates. If you have a quad you can just have 0,0; 1,0; 1,1; 0;1 as the UV for the verts of the quad, maybe scaling these taking into account the texture dimensions or the quad ratio. This is by no means complicated math, and I don't really know what you want us to tell you.

>>694669
I'm leaning towards going with a grid system, like the old Tomb Raider games. Then the UVs really are trivial to calculate.
I maintain that Sketchup and old level editors are doing something fairly smart, because they're so painless to use and just seem to "do the right thing" with textures. It might be as simple as good default scale values and heuristics to guess the correct orientation.

>>694674
Ahh for Christ sake, shut your fucking mouth Grandpa and just fucking learn Unwrapping. It's no rocket science. Put some effort in and learn the tools, its actually quite simple it just takes some time.

>>694680
I am unfortunately very familiar with unwrapping, having done far too much of it. I'll need to do plenty more for characters, items, and literally everything else that isn't the world geometry.

The game I intend to make will literally look like a mid-90s game. I'm doing it for fun and I want to design levels by just creating cubes and clicking on the texture I want each one to have.
You know, like the good old days, back when I was a whippersnapper making UT levels while walking uphill both ways to school.

I'm a lazy fgt and I just slap a triplanar mapping node on everything, durr hurr

i tried making a short movie with unreal editor.
tl;dr - don't do it unless you are classically trained with the editor. there is 1 web tutorial on the editor and that's it

>>694717
based

>>694666
>Prefabs
What are prefabs and why?

>>694743
he's saying that modern game environments are built with a modular workflow. Look at level asset packs for ideas

>>694674
>I maintain that Sketchup and old level editors are doing something fairly smart
No, it's literally just applying a texture to a quad which has square UVs. Do you want me to describe the basic collision detection algorithm used for dragging textures onto quads as well?
It's pretty clear you don't know the first thing about programming or rendering APIs, so I really don't know what you're trying to get at here, especially with statements like
>such that I might attempt to implement said system myself in a generalist 3D package.
You honestly seem like you're trying way too hard to sound smart, but these answers are pretty obvious to anyone who has even glanced at either opengl or dx.

>>694681
>>694837
Also, to add to this, just make a simple level editor, it's really fucking easy to do, especially if you're only using single texture cubes. This would 100 times superior to using blender or whatever to build your levels, for obvious reasons.

>>694837
t. armchair programmer

>>694840
What do you mean? I've been dealing with this for nearly 10 years now. I'm not too familiar with DX, but I know OpenGL, and it's mainly what I use. What part of what I said is "armchair programming"?

>>694842
Look up UV by World Cordinate.

>>695199
The process is the same, those UVs are just calculated through the worldspace coordinates. Worldspace UVs are hardly super smart. It's just coords in a quad referencing a texture map that repeats for U/V>1 or <0. And I've never seen any editor guess the scale value of a texture. In general, these things are applied based on the primitives they are based off of, but I might be misremembering that part (this means that textures inherit the rotation of the object, but if you start actually moving verts around you're gonna have a bad time).

As an example, in hammer editor, which is a fairly simple and primitive editor, you can see that these two quads do not line up, because the bottom one was rotated and the top one was created as is. If I'm not mistaken, old UE editors behaved the same.