Forum posts
I think I figured out your suggestion and it seems to work doing it manually, I'm now gonna write a script to do it and see how it goes. Thank you for helping me out!
So what you're saying is
But, isn't the original method already giving the UV a world space alignment since the camera remains at the world origin while projecting? Well, except for faces on edges, I suppose.
In those cases, even with the camera at the world origin, it treats the world UV as if it's at an angle. But with this new method, it aligns it with the world.
Still, when I transform the face by the normal, rotating it, won't that have the same result of having that rotated UV map anyway?
I've been doing Python in Blender for several years now but I'm out of my depth on this one. Never had to deal with normals and all this stuff before, not really sure how they work. Might just have to give up on this tbh, it's been a while I've been trying.
- I can reuse my existing code (see below) to determine the rotation of a face in world space.
- Then, I find which world plane (like XY, XZ, or YZ), I suppose by comparing the rotation values to find what it's closest to.
- Then project from the world origin on to those faces which aligns all of them to the world uv, even if they'll be stretched by the projection (so does this give me Hammer's 'World Alignment'?)
- Last, transform the face's world UV coordinates using the face's normal vector. I assume this involves simulating the rotation of the face in the UV space?
In those cases, even with the camera at the world origin, it treats the world UV as if it's at an angle. But with this new method, it aligns it with the world.
Still, when I transform the face by the normal, rotating it, won't that have the same result of having that rotated UV map anyway?
I've been doing Python in Blender for several years now but I'm out of my depth on this one. Never had to deal with normals and all this stuff before, not really sure how they work. Might just have to give up on this tbh, it's been a while I've been trying.
Blender doesn't exactly have a world UV coordinate system (far as I know), at least not like Hammer does. So the problem there is what to transform the face's UV from, since Blender doesn't give you a reliable starting place.
What I tried, and which does something similar I believe, is to move the camera in to a location that directly aims at the face, rather than staying in the world origin. That way it more closely replicates this behaviour. But it still isn't accurate...
...since even face projection still takes into account the world location. Maybe what you're suggesting is using this texture projection and offsetting from that based on the world location of the face?
What I tried, and which does something similar I believe, is to move the camera in to a location that directly aims at the face, rather than staying in the world origin. That way it more closely replicates this behaviour. But it still isn't accurate...
I've been trying to replicate Hammer's automatic face alignment in Blender using Python. I'm looking to get it 1 to 1.
I know from Valve that Face Alignment works by projecting on to the face depending on its angle.
I've written some code that goes over every face in my object in Blender, and aligns a camera (which is at the world originof (0 0, 0,) to rotate towards it and then uv project on to it. To put it another way, I'm replicating Face Alignment by getting the angle of the face, using that angle to rotate a camera (so the camera's view is parallel to the surface) and then projects a uv from the camera view on to the surface.
This actually works perfectly... for objects that are flat on the grid. But all other angles don't work quite right.
My issue is not that the process doesn't work, just that there isn't information I can find on how Hammer handles these arbitrary angles.
Left is Blender, right is Hammer. The textures are aligned 1 to 1. All the mesh is "flatly" on the grid.
These objects are at an angle and aren't matched up.
The following is how my script works:
The camera stays in the same location (the world origin) and rotates to match the angle of the face. It then projects the uv from the camera view. It does this for every face.
I know from Valve that Face Alignment works by projecting on to the face depending on its angle.
I've written some code that goes over every face in my object in Blender, and aligns a camera (which is at the world originof (0 0, 0,) to rotate towards it and then uv project on to it. To put it another way, I'm replicating Face Alignment by getting the angle of the face, using that angle to rotate a camera (so the camera's view is parallel to the surface) and then projects a uv from the camera view on to the surface.
This actually works perfectly... for objects that are flat on the grid. But all other angles don't work quite right.
My issue is not that the process doesn't work, just that there isn't information I can find on how Hammer handles these arbitrary angles.
The following is how my script works:
The camera stays in the same location (the world origin) and rotates to match the angle of the face. It then projects the uv from the camera view. It does this for every face.
Damn, how'd I mess that? Thank you Mad Carrot, I'll give it a look.
Thank you for the input, Admer. Your Decay stuff is part of what's got me intrested in learing Hammer!
I'm basing a mod off HL1 MMod and I'd like to add custom weapons, creatures and stuff to it. In my reserach about adding new weapons and creatures, I'm coming across needing to compile my own version of Source SDK.
I'm pretty sure MMod has its own fork of the SDK, which I don't think we have access to. Does that mean adding new content like that is impossible? Or can I still do it using the updated HL1 SDK and then run it through MMod reguardless?
This is my first attempt at a real mod of complexity so pardon if I don't know about even some basic principles. I'd just rather not spend my time figuring out getting it working if it's not possible with MMod because of not having the right SDK.
I'm pretty sure MMod has its own fork of the SDK, which I don't think we have access to. Does that mean adding new content like that is impossible? Or can I still do it using the updated HL1 SDK and then run it through MMod reguardless?
This is my first attempt at a real mod of complexity so pardon if I don't know about even some basic principles. I'd just rather not spend my time figuring out getting it working if it's not possible with MMod because of not having the right SDK.
I’m looking to add one (+1) or remove one (-1) from a counter.
I have a gameplay idea where players need batteries to open doors and power things. Batteries are scarce, but there are lots of places they can be used. So, when a player gets a battery, the counter goes up by one. When they use a battery, the counter goes down by one (so long as they have any).
I've read about the 'game_counter' but what I’ve read is it only works for exact matches (=) and can only count up. Conventional "key"s arn’t suitable here as batteries are not tied to specific doors, and their quantity across the map is arbitrary.
I thought about having two game_counters, one for "found" and one for "used", but I don't know of a way to check the state of
I have a gameplay idea where players need batteries to open doors and power things. Batteries are scarce, but there are lots of places they can be used. So, when a player gets a battery, the counter goes up by one. When they use a battery, the counter goes down by one (so long as they have any).
I've read about the 'game_counter' but what I’ve read is it only works for exact matches (=) and can only count up. Conventional "key"s arn’t suitable here as batteries are not tied to specific doors, and their quantity across the map is arbitrary.
I thought about having two game_counters, one for "found" and one for "used", but I don't know of a way to check the state of
found > used.