|
Imhotep posted:Is that Unity Humble Bundle worth getting? ( https://www.humblebundle.com/software/unity-2019-bundle?hmb_source=navbar&hmb_medium=product_tile&hmb_campaign=tile_index_2 ) A year's worth of Unity Learn Premium for that price is really good. The other course is dogshit, but whatever. The assets you may or may not use, but for that price they're a steal.
|
#
?
Sep 26, 2019 11:53
|
|
|
|
| # ? May 7, 2024 02:10 |
|
|
Imhotep posted:Lotsa That's pretty cool and I hadn't heard of it. In general, every game (or, really, every piece of software) is a bunch of simple systems piled on top of each other to hopefully make something that feels more complex than the sum of its parts. There are already a bunch of VR music visualisers out there, but my problem with them is they all do basically one thing. I wanted to make something more than "single morphing/moving object in 3d in front of you," but that's basically where you have to start and I'm starting to get to the point where the systems are there and good enough where I can just keep adding new content forever. My current problem is I actually have more knobs and dials worth of variables than I can figure out how to make a good VR interface for. Haven't thought of using camera inputs for anything but it could be a possible feature depending on how much of a PITA it is to access the cameras on a headset in a generic way that doesn't require me to own every VR headset out there.
|
|
#
?
Sep 26, 2019 12:56
|
|
|
Speaking of Humble bundles, is the Corel one worth picking up? Pinnacle +Paintshop pro ultimate + Painter 2019 seems like a good deal but I haven't used anything Corel in years.
|
|
#
?
Sep 26, 2019 14:45
|
|
|
Megazver posted:A year's worth of Unity Learn Premium for that price is really good. The other course is dogshit, but whatever. The assets you may or may not use, but for that price they're a steal. Also Playmaker is pretty awesome if you aren't a programmer first or very useful for collaborating with a non-programmer. Some of the assets look pretty food. I think it's probably worth getting.
|
|
#
?
Sep 26, 2019 14:57
|
|
|
KillHour posted:My current problem is I actually have more knobs and dials worth of variables than I can figure out how to make a good VR interface for. My immediate thought was to make one of these:  Dunno if it'd be good, but it'd be thematically appropriate!
|
|
#
?
Sep 26, 2019 15:07
|
|
|
Too fiddly. The sliders I already have are too frustrating to be precise with as it is.
|
|
#
?
Sep 26, 2019 15:17
|
|
|
I bought the humble unity thing but I already have playmaker. Go hog wild, someone: ASV-4GFJ-YK3C-KV9V-VFV3-Q6GY
|
|
#
?
Sep 26, 2019 16:18
|
|
|
Your Computer posted:anyway, the mipmapping isn't actually happening that close to the player anymore (might have to do with switching to Cinemachine for camera? I have no idea, I just noticed it when I opened the project today Looks great. Yeah I think most N64 games just used stretched super blurry textures for terrain because like you said, space concerns. I'm sure there's an exception but nothing immediately comes to mind.
|
|
#
?
Sep 26, 2019 16:59
|
|
|
Zaphod42 posted:Looks great. Yeah I think most N64 games just used stretched super blurry textures for terrain because like you said, space concerns.
|
|
#
?
Sep 26, 2019 17:14
|
|
|
I'd worked myself up for a terrible dive into the guts of the pathfinding package I've been adapting, only to discover this morning that it already includes undocumented functions that will provide exactly the extra info I need for my custom pathfinding agents. I'm both pleased that they exist and slightly annoyed at the documentation.
|
|
#
?
Sep 26, 2019 17:23
|
|
|
Corbeau posted:I'd worked myself up for a terrible dive into the guts of the pathfinding package I've been adapting, only to discover this morning that it already includes undocumented functions that will provide exactly the extra info I need for my custom pathfinding agents. I'm both pleased that they exist and slightly annoyed at the documentation. By coincidence, I was reading about A* last night, went "I bet I could implement that" and then find out that Godot just straight-up had a class for it already. Works fine for what I needed.
|
|
#
?
Sep 26, 2019 17:32
|
|
|
atholbrose posted:By coincidence, I was reading about A* last night, went "I bet I could implement that" and then find out that Godot just straight-up had a class for it already. Works fine for what I needed. A* is super classic, its the root of all pathfinding, so yeah, pretty common. But you should implement it yourself anyways, its a good exercise! Ehh, reading about it is probably sufficient. As long as you understand the alg.
|
|
#
?
Sep 26, 2019 17:38
|
|
|
Your Computer posted:point filtering by necessity, since I'm doing my own texture sampling in code. That said, the import settings for filtering are discarded anyway when using the shader since it supplies its own sampler state. Right. Too much info at once. Lemme try again. That visible fringe, the transition between mipmap levels is just something you're gonna get if you use mipmaps but not trilinear or anisotropic filtering, short of disabling mipmapping which will introduce aliasing artifacts instead. It's worth noting an amusing way to mitigate it somewhat, along with aliasing artifacts, is mentioend in what I've seen of the N64 sdk's manual: blur the texture in the first place as it'll make all those things less jarring. That's right, not only were N64 textures blurry due to memory limitations, the SDK was advising people to make them extra blurry. That's just delightful, in a way. As for where those thresholds lie, it's based on the screen space derivatives of the UVs. To put it simply, the GPU will determine how zoomed out the texture is in screen space and choose a mip level where the texture's texels are wider or at same width as the screen's pixels, so that there is no aliasing (which happens when you jump over several texels as you go from one pixel to its neighbor). That does mean that the mipmap transitions depend on render target resolution, so unless you fiddle with the numbers you'll get better detail that an actual N64 would give unless you match the output resolution (not that it really matters unless you're specifically trying to fake or emulate a N64's output to pixel perfection) Anyway, the CalculateLevelOfDetail thing (which certainly has an equivalent Unity macro) is there precisely because you don't need to know how that work but you may need the calculated value. Just pass the UVs to it and it'll return the mip level for the current pixel, but as a float. That is to say, if it returns 1.5 as the mipmap level, it means it's judged it to be halfway between level 1 and 2, so if you're not using trilinear filtering, just rounding it (well, using the floor or ceiling operator, can't remember which) should be fine. --- Now, I'm bothering you with all that because the 3-point filtering we discussed earlier has a bit of a flaw (common to all custom texture sampling schemes): it uses the pixel dimensions of the texture, or rather of the mipmap level you're sampling. If you sample a 64x64 or 32x32 textue with samples spaced for a 128x128 one, you don't get the right sampling anymore. You can see it happening in your splish splash video: the further mipmap levels have squares instead of the triangular interpolation, so at the very least when you made that one you weren't aware of the problem (although your lod comparison screenshot seems to do it correctly). I don't know if the texel size node in your shader node tree screenshots takes mipmaps into account but if it doesn't, you need to adjust your texel size values based on the current mipmap level. So the idea is to retrieve the mipmap level with CalculateLevelOfDetail, then your actual texel size is original_texture_texel_size * ceiling(2 to the power of rounded mip_level) if we follow standard mipmapping dimensions. Or, indeed, just not using mipmapping will get rid of the artifact. Chev fucked around with this message at 17:48 on Sep 26, 2019 |
|
#
?
Sep 26, 2019 17:44
|
|
That's basically implementing custom trilinear filtering isn't it?
|
They know the fringe is gonna exist they're just looking to make it happen further away from the camera so its not so noticeable. Makes sense its automatic based on resolution, but you should still be able to force certain LOD levels manually? Or just supply fewer levels so it doesn't swap until further out. Or just not mipmap, but they mentioned before they were wanting it to avoid issues with far away textures and still using that simple filtering. Zaphod42 fucked around with this message at 17:59 on Sep 26, 2019 |
|
#
?
Sep 26, 2019 17:52
|
|
|
I know they know. But if they want to move it they need to know why, and beyond that as the remainder of my post mentions the N64-style interpolation is busted mipmap-wise as it is. EDIT: Zaphod42 posted:Makes sense its automatic based on resolution, but you should still be able to force certain LOD levels manually? For them, the best option is to get the value from calculateLod, manipulate it in some way (for example by adding/substracting a constant to/from it), then pass the altered value to SampleLod. Technically there's a SampleBias function that should do just that, but like some other bias functions it's poorly documented (in fact its documentation is partially wrong) and without testing I can't guarantee it'll behave the same on all hardware without some extensive testing. It is a bit of a fool's errand because the mip thresholds will move depending on resolution anyway. You could also use a fixed resolution but as I said that could be pushing the N64 emulation too far. Using distance or some other alternative to derivatives or calculateLod to choose the mipmap level is just gonna introduce artifacts because hey, that's not how mipmapping works. Chev fucked around with this message at 18:36 on Sep 26, 2019 |
|
#
?
Sep 26, 2019 17:59
|
|
|
that's a lot of awesome info, thanks! I think I understand it a bit better now. Notably, I had already noticed that the mipmapping seemed "off" like you describe and I had to manually divide the texelsize to get it to work right in my mipmap experimentation  I tried to follow your advice about using CalculateLevelOfDetail though and all I'm getting is an error that I can't figure out. Trying to use the function in any way gives me the error "cannot map expression to ps_4_0 instruction set", and I even found a macro (CALCULATE_TEXTURE2D_LOD) which also throws the same error (unsurprisingly). fwiw I'm using Shader Graph for all of this
|
|
#
?
Sep 26, 2019 18:35
|
|
|
Alright! Well, there's several versions of the shader language(s) AKA shader models. Your Shader Graph is set to output shader code for pixel shader model 4.0 and CalculateLevelOfDetail/CALCULATE_TEXTURE2D_LOD is a pixel shader model 4.1 thing. There's probably a setting somewhere in Shader Graph where you can change that, otherwise you'd need to write the LoD calculation yourself, something I hope we can avoid (EDIT: well, technically it's like five simple lines of code, we'll just have to dig up a couple unity macros). EDIT: V V V Awesome 
Chev fucked around with this message at 19:09 on Sep 26, 2019 |
|
#
?
Sep 26, 2019 18:42
|
|
|
Chev posted:Alright!  a cheeky #pragma target 4.5 and it works! Now to actually implement it. I almost regret doing this in Shader Graph because it's still pretty wonky, I've never been able to create and use a sub-graph or include a function from a file so my graph's getting pretty messy 
|
|
#
?
Sep 26, 2019 19:02
|
|
|
TooMuchAbstraction posted:Tried to make a new gunflash effect, came up with this thing instead: I'd suggest checking this out for muzzle flashes https://youtu.be/AOcxfvt5aDU
|
|
#
?
Sep 26, 2019 21:38
|
|
|
MithosKuu posted:I'd suggest checking this out for muzzle flashes Yeah, I'm familiar with the Corridor Digital crew and I've seen their muzzle flash breakdown. I have an existing explosion effect that's doing an OK job; the big problem it has is that it's a flipbook (a sequence of hand-drawn explosion frames), and when you're seeing a lot of flashes go off (which you will, since you can basically tape the fire button down in this game) it becomes very obvious that they're all just minute variations on each other; I want more variability. For things like what Corridor Digital is doing, flipbooks are less of an issue, because even during an action scene very few frames have flashes in them, and they don't draw the eye as much as what the characters are doing. I was basically just noodling about with my differential-scrolling-textures shader (takes multiple textures, offsets them by variable amounts, and multiplies them together) to see if I could get a procedural effect that looked decent. I can get decent colors, but getting that with a procedural shape is beyond me right now. I think probably I need some hand-drawn mask textures to give the right shapes, and then I combine those with the differential-scrolling shader to fill in the color info. Or something along those lines. Regardless, this really isn't that high of a priority...I just don't really feel like working on anything important today. Bleh.
|
|
#
?
Sep 26, 2019 21:52
|
|
|
Your Computer posted:see this is the kind of stuff I literally could never figure out on my own
|
|
#
?
Sep 26, 2019 22:05
|
|
|
Regarding the talk about Steam Pipe being poo poo/hard to work with, I actually made a goofy documentation PDF covering the process for our own company if anyone wants to use it to figure up how to upload builds and stuff. I still refer to it from time to time because I forget so easily and Steam's own documentation buries the lede. Also unlike Steam's documentation, it is written from the perspective of an innuendo-laden plumber so make of that element what you will.  https://drive.google.com/file/d/13aX0OJ9dmsixNOzvnGNdV6NnfZBznJhK/view?usp=sharing Also I'm struggling right now trying to tune our movement. It's my first time truly tweaking around with 3D rigidbodies in such a manner (in the past I've always used real out-of-the-box third person controllers or whatever) and I'm not sure what I'm doing that's causing such sluggish movement (except when moving diagonally) that somehow also manages to feel floaty when falling, and unable to traverse hills. I made a little video of how our current movement feels right now. It's real bad. https://www.youtube.com/watch?v=3wKx8sxvgwI Bert of the Forest fucked around with this message at 23:39 on Sep 26, 2019 |
|
#
?
Sep 26, 2019 23:34
|
|
|
Now, instead of barfing when starting from or going to a position inside an obstacle, my agents will look for the closest valid position to path through instead of crashing and/or clipping into said obstacle.  I mean they're kind of dumb at it still, but it works. It looks a lot more impressive in the VR headset, I promise. 
|
|
#
?
Sep 26, 2019 23:41
|
|
|
Bert of the Forest posted:Also I'm struggling right now trying to tune our movement. It's my first time truly tweaking around with 3D rigidbodies in such a manner (in the past I've always used real out-of-the-box third person controllers or whatever) and I'm not sure what I'm doing that's causing such sluggish movement (except when moving diagonally) that somehow also manages to feel floaty when falling, and unable to traverse hills. I made a little video of how our current movement feels right now. It's real bad. Off the top of my head, I'd check the following:
Thanks for the Steam notes. Hopefully someday I'll need them!
|
|
#
?
Sep 26, 2019 23:43
|
|
|
Chev posted:To be fair I've been throwing you pretty far down the shader rabbit hole recently. If it weren't for N64-style filtering you wouldn't need most of that stuff. I'm finding this stuff super fascinating, but it's also frustrating due to how hard it is to find information in order to figure stuff out. As an example, the error from earlier only returns like 5 results on google, none of which explain what it means or is in any way relevant to my problem. That said, I'm now wondering how hard could it really be to extend this to trilinear filtering (the answer is  because I can't find any implementation details on that either)oh, and I figured out why the mipmapping was kicking in further away suddenly - I had switched from 'Free Aspect' to '16:9' in Unity's game window earlier.
|
|
#
?
Sep 27, 2019 00:23
|
|
|
Bert of the Forest posted:Also I'm struggling right now trying to tune our movement. It's my first time truly tweaking around with 3D rigidbodies in such a manner (in the past I've always used real out-of-the-box third person controllers or whatever) and I'm not sure what I'm doing that's causing such sluggish movement (except when moving diagonally) that somehow also manages to feel floaty when falling, and unable to traverse hills. I made a little video of how our current movement feels right now. It's real bad. Is there a reason you are using a straight rigidbody? I've found they are impossible to get 100% good movement from them. You can spend ages tweaking to get it to work most of the time, but that final polish to make it work absolutely-all-the-time just never comes. I've never actually seen a commercial Unity game that used rigidbodies for players except goofy fumble stuff like Grow Home. If they aren't using the CharacterController (which has its own wonkiness) they are using a kinematic controller like this one. It seems like full physics players are a fine game jam thing that falls apart in extended usage.
|
|
#
?
Sep 27, 2019 00:44
|
|
|
OK,so since I coupled the logic of my game with the animation code,I couldn't implement level generation (which is just inputing random tokens into a generated level until every part is triggered withing a reasonable number of inputs,and make the resulting sequence the target pattern) in the background.Solution: Speed the animations way the hell up and make that the loading screen  I'm calling this attempt finished,so here you go - my first game and it's technically playable 
|
|
#
?
Sep 27, 2019 01:56
|
|
|
Doesn't that mean the loading screen gives the answer?
|
|
#
?
Sep 27, 2019 02:05
|
|
|
KillHour posted:Doesn't that mean the loading screen gives the answer? WAY the hell up.I can't imagine anyone following it. https://imgur.com/a/floVkYC Although now that I think about it,should I add an epilepsy warning?
|
|
#
?
Sep 27, 2019 02:25
|
|
|
Throw some postprocessing motion blur on it and call it a day, IMO.
|
|
#
?
Sep 27, 2019 02:27
|
|
|
Your Computer posted:That said, I'm now wondering how hard could it really be to extend this to trilinear filtering (the answer is  compare built in trilinear filtering (left) to my own filtering (right) with a pure gray mipmap for visualization   now, is this something anyone would even notice? no. But was it still worth it to go through all this trouble? probably also no
|
|
#
?
Sep 27, 2019 11:34
|
|
|
Bert of the Forest posted:Also I'm struggling right now trying to tune our movement. It's my first time truly tweaking around with 3D rigidbodies in such a manner (in the past I've always used real out-of-the-box third person controllers or whatever) and I'm not sure what I'm doing that's causing such sluggish movement (except when moving diagonally) that somehow also manages to feel floaty when falling, and unable to traverse hills. I made a little video of how our current movement feels right now. It's real bad. Are you applying forces when keyboard buttons are held down? If you're applying X impulse to the right when right is held down and X impulse up when X is held down then the character will end up moving at 2X speed diagonally, when actual diagonal motion should be sqrt(2)X ~= 1.4X. Or at least, that's what it looks like is going on. I'm not exactly sure how you implemented things but try having a higher acceleration and a lower (or the same) max speed.
|
|
#
?
Sep 27, 2019 14:18
|
|
|
Your Computer posted:well it took me a day of really thorough digging but I think I did it It looks real nice!
|
|
#
?
Sep 27, 2019 15:48
|
|
|
I'm looking at the Corel Humble Bundle. Right now my art is either 3D stuff with free textures, vector art I make in Inkscape, or noise textures I bodge together in GIMP. Of those three, I'm most interested in getting away from GIMP; how is Corel's noise rendering support? GIMP pretty much just has difference clouds if you care about making tiling textures. It's a bit limiting.
|
|
#
?
Sep 27, 2019 16:34
|
|
|
Can anybody here suggest good examples of well-executed in-game menus in FPS (or similar) games? I'm trying to work out how I might implement a way for players to quickly bring up a way to choose between say, half a dozen on-screen options, but without leaving them sitting-ducks in a multiplayer game (ideally they would still be able to run around while selecting). I've tried radial menus in the past and I think my implementation just sucked. But I'm keen to see if there are any better directions to go in.
|
|
#
?
Sep 27, 2019 19:30
|
|
|
Evrim posted:Can anybody here suggest good examples of well-executed in-game menus in FPS (or similar) games? I'm trying to work out how I might implement a way for players to quickly bring up a way to choose between say, half a dozen on-screen options, but without leaving them sitting-ducks in a multiplayer game (ideally they would still be able to run around while selecting). CS maybe? The buy menu is quick and consistent. You can't run around but everything has quick hotkeys that are easy to learn so you can tap through it in half a second. Otherwise, yeah, radial menus? I'd be curious to know more about context. Why do you need menus in the middle of a multiplayer game at all? Should be avoided if at all possible, moved to when you die or something. This some multi fpsrpg? All I can think of is like, spawning vehicles in tribes...
|
|
#
?
Sep 27, 2019 19:45
|
|
|
Yeah, it's things like activating special skills. Since you mention CS, you reminded me that I should also check out the TF2 spy menu, since that has similar requirements (need to be able to select a disguise quickly while running around).
|
|
#
?
Sep 27, 2019 19:59
|
|
|
Your Computer posted:now, is this something anyone would even notice? no. Congrats on making it work!
|
|
#
?
Sep 28, 2019 00:42
|
|
|
Evrim posted:Yeah, it's things like activating special skills. Since you mention CS, you reminded me that I should also check out the TF2 spy menu, since that has similar requirements (need to be able to select a disguise quickly while running around). TF2 Spy menus is kinda like I said with the guns where you generally learn to memorize a few key numbers so you can hammer them quick, like Soldier or Demoman.  That consistency and unique numbered keybinds are key for speed and reliability. I guess you can still move around while using the disguise menu though, true! If you're talking about special skills, I would really really try to have them all visible on the HUD at all times and give them each unique keybinds if possible. That's generally the industry standard. How many skills do you have?
|
|
#
?
Sep 28, 2019 00:49
|
|
|
|
| # ? May 7, 2024 02:10 |
|
|
I spent today working on implementing superstructures for my ships. Superstructures are basically buildings that go on the deck to provide internal spaces for whatever -- radar, fire control, damage control, etc. In my game what they do is provide a "volume" stat that can be used to purchase such systems, so e.g. a level-2 radar room might require 100 volume and give a radar range of 300m. To reduce the fiddliness for placing them and make them a bit more realistic-looking, I allow them to intersect with bridges and smokestacks, at the cost of reducing the amount of volume they provide based on the degree to which the parts' bounding boxes intersect. The big problem I have with this first-pass implementation is that you can basically overwrite the bridge with a big blocking superstructure, which looks ugly:  If you missed it, the bridge is a bit left of middle on the ship. I'm not sure if this is actually a gameplay problem though -- you have to pay full price for the mass of the superstructure, while getting little benefit in terms of usable volume. It just looks ugly. I guess I could mitigate it by limiting the height of superstructures that I allow to intersect with things like bridges, but that sounds irritating to implement and hard to communicate to the player. I could also only allow bridges to be placed on top of superstructures, not intersecting them, but then you need to find a single superstructure block that's big enough to provide a base for the entire bridge (a part can't be supported by two other parts, only by one). Any ideas or opinions?
|
|
#
?
Sep 28, 2019 01:27
|
|