Yes, the next thing I am going to be working on is the level editor. I didn't actually plan to do this for quite a while because it seems like a nice but not essential feature to have. For reasons I will make clear shortly, I need to build the level editor before I can continue.
What is this garbage?
Menus are the best showcase of my work.
Wrenching animations
I'm so sorry for the pun. What I really wanted to work on after the procedural fracturing was repairing of the fracture sites. Hit the debris with a wrench until it's close to its non-fractured position, and then weld it into place. Here's a spiffy gif of the wrench animation:
+1 for perfectly looping wrench
Here is a video, but it's not the greatest. Everything is 100% broken at the moment; I guess that's what I get for building my game with the Unity betas.
The video shows off some cool stuff, even if it looks horrible. There's the inverse kinematics on the hand placement. Inverse kinematics is a way of calculating the shoulder, arm and elbow position required to place a hand at a certain position. There's also the physics on the debris and well, you can see the lighting is broken (Unity's fault) and the scale is all weird (my fault).
Everyone is three feet tall
That's right. The reference I was using for the scale and level layout pretty much has everyone being three feet tall. After making the wrench animation, I naturally tried to apply it to a character and animate it. The problem here is that a standard character model is 1.8 meters tall, or almost twice the height of the ship. Changing the scale of the ship to be twice as tall reveals just how incredibly cramped the place is.
It's interesting how making the place bigger actually makes it look smaller.
Scaling the character models is a no-go because you'll have to scale down all the animations too and reimporting stuff is a nightmare in general. The ultimate conclusion is that I'm going to have to build the level editor a lot sooner than I expected. I need to test out different scales and room sizes, and I can't do that easily with my current set up. As for the level editor itself, Unity editor scripting is in some respects quite easy, but implementing a custom tool for laying out floor pieces and walls is difficult. There is some artificial difficulty here because most of the problems are caused by the complete lack of documentation. My techniques thus far have relied on snippets from the forums and wishes. Example: Editor.OnSceneGUI()'s documentation consists of:
function OnSceneGUI () : void
Description
Lets the Editor handle an event in the scene view. In the OnSceneGUI you can do eg. mesh editing, terrain painting or advanced gizmos If call Event.current.Use(), the event will be "eaten" by the editor and not be used by the scene view itself.
That's all you get. Now go implement a level editor!
...It's coming along, but there are bugs and I don't really know what I'm doing. Expect to hear more about the level editor next time. Also, it's my last week at Intel(!!!). Let's all celebrate this new era of starvation and potential homelessness!
Hey! If you missed it, yesterday I wrote an artisanal blogue poaste about a tool I am working on called the HDR injector . Today, I will write about how to present an HDR image in Windows. Some of this will be a summary of the talk by Evan Hart at GDC 2018. There are three steps, which I don't think are explained anywhere, except maybe within these ultra-rare DX12 samples that I had to catch midair from a hot tweet. Set your swapchain effect to DXGI_SWAP_EFFECT_FLIP_DISCARD . Emphasis on FLIP. The GDC talk above seems to think this isn't 100% required, but I couldn't get any HDR working without it. Set your swapchain buffer format to an HDR compatible backbuffer format. The ones that work for me are: DXGI_FORMAT_R16G16B16A16_FLOAT and DXGI_FORMAT_R10G10B10A2_UNORM , though I expect other formats might work. I haven't tested all of them. Depending on which format you picked in ( 2 ) you need to select the correct color space. If you selected RGB...
Hi everyone, It's blob time! This is a long one so buckle up. If you haven't been following along on my tweeter for the last month, I've been working on simulating and rendering blobs. Here's a dump of my progress (easily accessible from the hashtag #vectorboy64 ). I'll add some captions This first one is just me trying out position based dynamics and the constraint functions. PBD is a really cool way to simulate physics, and I'm really happy with how flexible it is and how easy it is to implement. I'm definitely going to use it for some other stuff in the future. position based dynamics with oscillating pressure and distance constraints #vectorboy64 (???) pic.twitter.com/ZOa6QLtndR — Kelly Jelly rebs your zankage and distunks you. (@pyromuffin) January 9, 2019 I spent a really long time trying to figure out the gradients of some tricky vector math formulas. I have them mostly correct, but there are still spurious rotations like this in the ...
Hello, Today's galaxy brain idea is to use integer math to do arbitrary rotation about a point. Why? I can already hear you saying "We have very nice floating point units that are good at this already!" and I say, No thanks to the floating point unit. They're all well and good, but converting between floats and ints is slow on the GPU, wasting a whole instruction and especially so when you want to do index calculations. Also consider that on newer versions of GCN, we have packed ops, but no packed float/int conversions. Also, also consider that GCN doesn't have scalar floating point ops, and if you want to do float math in a scalar context, you'll be issuing vector instructions with SGPR sources! If you are maxed out on VALU and want to offload some calculations to SALU, then you're only making your problem worse if you need to do floating point ops. Think about the index rotation case: read in some integer index data, maybe a thread...
Comments
Post a Comment