Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Solifuge]

I'm not sure I get your requirements or goal... but I'd suggest making your own Cube Model in Blender if the Unity one is giving you trouble. Unity's all use one texture for each face, and are kinda wonkus. If you make your own texture to be used on the faces (or a texture sheet for each face, or whatever) you can then assign the model UVs to make the texture look the way you want it to, and export it for Unity.

Then, in Unity, you can replace the texture in the Material for that object with any other texture (or texture sheet done in the same style) and it'll apply it to the mesh. You can do this by script too, by accessing the Material's mainTexture component.

[Parsely]

I'm not sure I get your requirements or goal... but I'd suggest making your own Cube Model in Blender if the Unity one is giving you trouble. Unity's all use one texture for each face, and are kinda wonkus. If you make your own texture to be used on the faces (or a texture sheet for each face, or whatever) you can then assign the model UVs to make the texture look the way you want it to, and export it for Unity.

Then, in Unity, you can replace the texture in the Material for that object with any other texture (or texture sheet done in the same style) and it'll apply it to the mesh. You can do this by script too, by accessing the Material's mainTexture component.

I want to be able to texture individual faces of game objects within Unity so I can quickly drag-n'-drop to swap faces out to make new cubes. By this I mean I want to have 6 textures, one for each face, rather than having to edit UV maps manually when I want a new cube. Being able to change textures at runtime would be cool too because then I could show damage on individual faces of the cube, but the ultimate goal is just to be able to quickly build objects that represent the environment without needing to build and export them from Blender.

I guess at this point maybe I should be considering building levels out of planes instead of cubes. That would give me some more flexibility with the way levels are shaped...

Yeah I made a cube in Blender and exported the UV map into Unity, but I wasn't sure what to do once I had those. I did all kinds of weird stuff with Vector2s in the scripting but I had no idea what I was doing. At one point I got it to sort of work but the faces didn't render properly. When I get home I'll be trying again.

[Solifuge]

If you want to do that and avoid mucking with UVs and texture sheets, I'd suggest building your environment out of planes, yeah. That'd be the easiest solution, though depending on the number (if you're talking in the 100,000s of tiles) that could slow you down a bit, just from sheer number of Game Objects. Just something I learned from building very large map-tile systems!

[itisnotlogical]

I'm going to try and learn UE4, as much as one person can learn such a complicated tool.

Shortly after installation I'm already very excited by the node-based shader editor, compared to Unity's "fuck you, figure it out yourself" approach to custom shaders. I also like the idea of a timeline-based cutscene editor, a feature which is only just now coming to Unity.

I am less excited by Visual Studio being the default code editor. Every past attempt to use Visual Studio (or any modern Microsoft product, for that matter) has been about as quick and painless as a trip to an unholy hybrid of the DMV, the dentist's, and the principal's office. For all of MonoDevelop's shortcomings it never behaved like a clingy ex-girlfriend, telling me about expired licenses and TeamShare every time I come around.

[Parsely]

I prefer Visual Studio by miles, but with Unity it's not as smart as it normally is when using vanilla APIs.

[Dark One]

Some of my latest WIPs for my project running under Darkplaces engine.





These screenshots are before UV Mapping and I'm still working on textures.

[Telgin]

I'm going to try and learn UE4, as much as one person can learn such a complicated tool.

Shortly after installation I'm already very excited by the node-based shader editor, compared to Unity's "fuck you, figure it out yourself" approach to custom shaders. I also like the idea of a timeline-based cutscene editor, a feature which is only just now coming to Unity.

I am less excited by Visual Studio being the default code editor. Every past attempt to use Visual Studio (or any modern Microsoft product, for that matter) has been about as quick and painless as a trip to an unholy hybrid of the DMV, the dentist's, and the principal's office. For all of MonoDevelop's shortcomings it never behaved like a clingy ex-girlfriend, telling me about expired licenses and TeamShare every time I come around.

While I like Visual Studio for other kinds of application development, I was a bit put off by how daunting it looked when used with UE4.  UE4 required tons of macros and strange decorators to be sprinkled around class definitions, and I didn't even want to bother learning how to use it when the node based editor worked as well as it did.  Didn't help that I did have some issues getting Visual Studio to work with it.  Having an older version installed kind of screwed it up when I installed a newer version, since UE4 kept wanting to launch the old version.  Can't remember how I fixed that.

I've been doing some work in UE4 for a few months now and managed to build a functional prototype for a pseudo twin stick shooter without having to write any code in Visual Studio at all.  Animation, shaders, weapons, inventory management and environment interaction are all handled with blueprint behavior graphs.  No code needed, and I think it's better for it so far.  I haven't really felt the need to write anything in C++ yet.

If you go that route, I do advise you to make heavy use of custom events and custom functions to keep the graphs clean.  I didn't realize you could create custom functions for a while and some of my blueprints are kind of cluttered as a result.  I need to go back and clean them up at some point.

[itisnotlogical]

I do quite like blueprints! I created a third-person character that feels pretty good to control, in about half the time it would have taken in Unity. A lot of the math and physics has already been figured out and put in the CharacterMovement component, which saves time on implementing (for example) air control. It's pretty easy, like Game Maker on steroids.

One thing I don't like is that a blank UE4 project (with "Scalable 2d/3d" picked) seems to automatically turn on a lot of graphics options that just slow the game down without good reason; SSAO, reflection passes, fog, bloom etc. PC master race yadda yadda whatever, I believe there's value in making games performant across a wide range of devices, my little ol' laptop included, and I'd rather turn on these options as I decide I need them rather than having them all on from the start. Still, that's only a small annoyance compared to the time saved and features offered.

[Telgin]

I agree about the performance settings.  If I leave the editor window in real time mode (I think that's what it's called), my computer sounds like a hurricane from all of its fans running at max.  I'm getting about 90 FPS with the current quality settings and load of less than 100K triangles on my desktop, but on my laptop it dips to about 20 FPS.  My laptop can play games made in the last few years at acceptable frame rates, so I'm sure it's just a quality thing.

Unrelated to that, I'm currently trying to work out some problems with aiming.  I'm not sure how professionals get aim offsets to be so perfect, but I'm guessing it involves creating the weapon sockets in their modeling application and fine tuning them there rather than adding them in UE4's editor.  I've tweaked the rotation of my character's gun a tiny bit repeatedly and he's still aiming slightly off from where the mouse is.  Oh well, I can work on that later.  Currently learning how to do interfaces through UMG, and that's turning out to be an adventure.

[itisnotlogical]

Wouldn't it make more sense to do some math to aim the gun in code (via an animation offset or just rotating the entire character) rather than manually tweaking the model in the editor?

Another alternate is to make it so that during the firing animation they bring the weapon closer to their center of mass, so it's more of a straight line from the center of the character to the mouse cursor.

[Telgin]

Yeah, moving the weapon closer to the center line would help, but it's still not a perfect solution.  It's also complicated by the kind of hacky movement animations I had to make.  I might get some screenshots to show what I mean when I get home, if I can remember.

What I'm doing is converting the mouse location to worldspace and finding a rotation offset from the character to that.  I feed the pitch and yaw into a blendspace to calculate the pose needed to aim at the location (it's not an actual aim offset, since I couldn't get those to do exactly what I wanted).  The projectiles are then created from the tip of the barrel, which depends on the weapon being pointed at the spot you're aiming for.

What's happening is that since the gun is offset from the center line, it hits a spot next to the mouse cursor.  That's fine since I can probably just adjust the aim yaw with some trigonometry to fix the problem.  The issue with the model is that the socket on the skeleton, which the gun attaches to, doesn't perfectly match up with the animation.  So, if the pose comes out to aiming dead ahead (0 yaw, 0 pitch), the socket is maybe pitched down by 1 degree, causing the shots to miss.

I'm not really sure how to fix that problem.  The base pose for the model is an 'A' pose, so I can't just key in the socket rotations like I'd want, since the socket needs to be rotated down by 45 degrees to match the pose, among other minor adjustments to make it fit.

I think most people make the sockets in the modeling program, which I can try.  Blender's FBX export has some quirks though, so I've been afraid to try it.

[Parsely]

I'd love to see screenshots.

[Telgin]

Took a little longer than anticipated, but here we go.  You can see in the images below how the aim is off.

The white sphere is a debug sphere drawn at the worldspace location corresponding to the mouse position.  When you right click, the character switches to aim mode and tries to point the gun at that spot.  The red line is a debug trace from the barrel tip to where the gun is actually pointing.





So, you can see that the shots are hitting to the side of the target, which is because the gun is being held to the right of the character's center of mass.  However, it's also overshooting slightly, as you can see in the second image.  That, in turn is caused by the gun not being perfectly level.  That's shown below.



That's the base, aim straight ahead pose, with 0 pitch and 0 yaw.  It's hard to see, but the rifle is pitched upward ever so slightly, causing the aiming discrepancy.  The problem with fixing it is that, as far as I can tell, you can't edit the socket rotation from an animation.  Instead, you have to edit it from the base pose, which is below.



The rotation parameters for the hand socket are really screwy.  When I first attached the socket to the hand joint, its rotation and position were wildly wrong.  I tweaked it as much as I could, but it required adjusting the pitch, roll and yaw, so I can't just key in that I needed a 90 degree roll, for example.

Again, I think the way this is normally solved is to create a special joint in the skeleton that you export as part of the .FBX, which Unreal interprets as a socket.  That way you can make sure it's right in the modeling program.  Unreal was built with Maya in mind, supposedly, and Blender's .FBX export has some issues, so I'm not sure it'll work like I intend.  I haven't tried it yet though.  More to the point, I had some major issues trying to get the dummy gun model in Blender to stick to the hand like it was supposed to in the first place, so I suspect I'll be fighting Blender more than Unreal.

Related to sockets, I haven't figured out yet why they seem to lag behind animation slightly.  The "hair" on that model is attached to a socket on the head, and when he runs you can see the hair moving a frame or two behind the rest of the animation.  Very strange.

Another bug I haven't figured out yet is shown below, where the aiming reticle in the UI gets placed in an obviously incorrect location when aiming in certain locations.  I think it happens when the collision trace from the gun hits nothing and the screen projection defaults to 0,0 or something.  Still, in this image I'm clearly aiming at the ground and yet it still happens.



I should probably be asking these things on the Unreal support forums, now that I think about it. 

[itisnotlogical]

Could you do a trace from the end of the gun and place the reticle based on that? Or is it important that the reticle totally match the mouse?

[Telgin]

That's actually how it works now.  I was thinking it would be fine if the reticle tracked where the gun was pointing instead of following the mouse directly, but that causes some weird disconnect with terrain and obstacles.  If you move the mouse to the left and the gun points toward a hill, for example, the reticle will move to follow the hill instead of tracking left precisely to match the mouse.

It just feels weird if you can't also see where you're trying to aim, so I think I really need to add an indicator for the mouse position and where you're actually going to hit.  To that end, I need to make sure the gun actually points at the mouse cursor.