deftware

  • Apr 29, 2018
  • Joined Apr 12, 2018
  • 0 best answers
  • Yea, you can't just add normals together and divide by half to get a new normal. You just have to sum them and normalize that to get a new unit vector normal.

    i.e.

    NORMALMAP = normalize(mix(n1, n2, 0.5));

    that will combine them at 50% and give you a proper normalized unit vector that can be subsequently used for lighting calculations.

    Even the original shader you started with did that, you just weren't using a mask that was mixing them the amount you wanted. Your textures don't even look like they're the same as your 'reference', they look like rougher approximations reproduced procedurally.

  • I'd love to be able to extract meshes from UE4/Unity asset packages. There's so much good stuff out theres.

  • I think Godot's documentation will get there. It's gaining more attention, notoriety, and respect from the gamedev community as a whole, which is going to cause more cries of "we need documentation!" at which point devs will have to go back and write it out. Sure, people would make cool stuff a lot faster if we already had more/better documentation, and thus attract more interest in Godot, but we'll get there. There's a bit of stuff that nobody has any idea about, like WTH is a ProximityGroup node for? Who the hell made it, and what does it do? The API 'documentation' doesn't explain anything at all about it that makes it useful in any way. Whoever is responsible for creating it will come around to making sense out of it for us eventually I figure. The same goes for everything else in Godot that's somewhat of a mystery. Otherwise, there's at least a good number of people who already have made sense of a lot of stuff in Godot, who have been working with it for a lot longer than most, and are dispensing explanations and tutorials. Thank god for them, yessir, otherwise we'd be mostly lost.

  • I cannot find anything about this thing, other than evidence that I'm not the first person to inquire as to what it does. Or can someone more experienced try some experiments and deduce what it does? It seems like it could be very useful for spatial searches. Thanks!

  • I'm coming at Godot with no Python or Unity experience, but I have been doing hobby gamedev and game engine development/programming for 20 years. I find it hard to make sense of things like networking in Godot because I've always had to approach everything from the lowest possible level (i.e. sending raw UDP packets exclusively) and build up my own systems from scratch. That's something I've done multiple times over the years, for networking, physics, graphics, scripting, etc. but I am only good at it because I know what the rules are starting with just the raw elements to work with.

    Networking in Godot (and GDScript in general) is trickier for me to learn than I thought it would be just because it makes many things much easier than doing them from scratch the way I'm used to, while other things remain just as complex as if they had to be implemented from scratch. There's no clear delineation as to what functionality already exists and what functionality we need to write ourselves, and if there is, it usually only applies to one way of doing something among a set of different ways of going about it, and there's not really much in the way to help us discern the different ways from each other.

    But this is what I call "reverse engineering"... Not "tutorial"

    I agree, wholeheartedly. I feel like there's enough different ways to do things that there should be some explanation as to the 'why' of the 'how'. At any rate, I'm sure I'll be wielding Godot within the month and perhaps I'll contribute some tutorials once I get the ball rolling on the project I plan to use it for. In spite of there being much documentation about the interface and how stuff works, and tutorials to do all kinds of little things, it seems as though there's still a pretty sizable dearth of information regarding how to go about actually making games with Godot that piece together the various tidbits of know-how.

  • In my experience we've always used an 'attack_finished' time variable, which you set to the current time plus some duration for the attack interval. Then in your input code that translates input commands into player actions, you just check if the current time is greater or less than the attack_finished value.

    If the current time is greater than attack_finished then that means that enough time has elapsed since the most recent attack action. Otherwise, it means that the most recent attack occurred less than the amount of time added as the interval, and nothing should happen.

    This is how I've always accomplished a sort of rate-of-fire on weapons and other actions.