Jump to content
Ultra Engine Community

nick.ace

Members
 View Profile  See their activity

  • Posts

    647

  • Joined

  • Last visited

 Content Type 

Posts posted by nick.ace

    Additional buffers for postprocessing

    in Suggestion Box

    Posted

    Yeah sorry, on second thought your example wasn't the best example. I was more or less thinking of just silhouettes, and with another buffer you could modify SSAO to ignore changes in depth. Anyway, the heat haze example would be more appropriate.

     

    But anywho - so your request is that you want the ability to write to custom buffers/channels specified in a model shader?

     

    Yes, that's what I want.

    Additional buffers for postprocessing

    in Suggestion Box

    Posted

    Yeah, but that's slow. You have to do up to twice the transformations on the CPU. You also have to send up to twice as much data from the CPU to the GPU. Also, you don't get to take advantage of the GPU discarding nearby fragments, and you still end up using two buffers (actually, probably all of the buffers because you have to render the second world). If lights are in the scene, you would have to rerender all of the lights twice. Basically, it's not fast, which is why if you have transparency has a high performance hit for deferred renderers.

    Additional buffers for postprocessing

    in Suggestion Box

    Posted

    Yeah, but those are made after everything rendered (during postprocessing). I want to write to custom buffers using the fragment shader of the models. So for heat haze for example, you would want it to be occluded since it's a depth-based effect. The fragments that are visible at the end of this should have a special effect applied to them. Currently you can kind of do this by overloading the alpha channel of the normal buffer if you're careful (because it's used for other things a well such as decals and selection state for the editor)

     

    So, being able to write to FragData3, FragData4, ...

     

    Another example is your cool effect:

     

    You have to do two passes right? Well, if you could write to an x-ray buffer instead, you wouldn't have to do this. You would definitely need another buffer for this to do in one pass because the occluded fragments get discarded by the GPU (unless you mess with the depth buffer, but then that messes up a ton of stuff).

    How can I make this look better

    in Game Artwork

    Posted

    Suggestions:

    1. You definitely NEED SSAO. Really it's a must for any indoor environment (but is great outdoors too).
    2. Add decals all over the place. Otherwise, the environment won't have character.
    3. Add bloom to make the lights shine more. But don't turn this too high.
    4. Like other said, make the ambient light darker. But also, I would avoid making it a grayscale color such as (15,15,15), but that's probably just my personal taste.
    5. Add particle effects unless it's supposed to be super clean.
    6. (Optional) DOF. I love it, but it's technically not realistic. It's more of cinematic effect really.

    • Upvote 4

    Static Models

    in Game Artwork

    Posted

    No, it's a deferred renderer, so it does a few things:

    1. It calculates the depth, normal, and color of the final fragments in the scene and places them in buffers (basically renders each of those into an image).
    2. A lighting shader is then used to calculate the lighting. This operates on each fragment. You can think of the lighting shader as a post-processing effect to some extent.

     

    A fragment consists of primarily: depth value, normal vector, and color value. It does not contain the UV. And this is the same regardless of whether a model is static or animated.

    • Upvote 1

    I'm new to all this.

    in General Discussion

    Posted

    Those benchmarks are completely irrelevant:

    1. They are testing on computationally expensive algorithms, not games. Those benchmarks aren't even labelled as gaming related benchmarks. As far as I know, using Haskell for gaming would be a horrible idea!

    2. They are likely not using a LuaJIT compiler. Of course a scripting language is going to be slower without caching the results. Even comments will contribute to speed loss at that point. If Lua were so slow, why do AAA games use it? Here's a benchmark for LuaJIT: http://luajit.org/performance_x86.html

    3. Lua in Leadwerks (and any reasonable game engine that uses Lua) used compiled functions from the API, so even the computationally expensive parts (like pathfinding) are only going to be negligibly slower since you are effectively calling the same piece of code as you would in C++.

     

    Also, I don't think anyone is saying that he's wrong to do something. A lot of us have a lot of programming experience and have seen people struggle trying to learn things a certain way and don't want newcomers to make the same mistakes.

    urWorld April Release : Water, Water Everywhere

    in Showcase

    Posted

    I love the presentation and art direction! It honestly looks like a AAA or high quality indie game in it's current state. And the mechanics in general seem to be very polished along with the menu.

     

    Is it possible to automatically select the native resolution though at startup (unless otherwise specified)? My monitor flickers and causes all open windows to readjust, which gets kind of annoying.

     

    Maybe add some feedback as well to dragging items onto things like the campfire. I didn't really know at the time what would and wouldn't work.

     

    Looking really good though! Can't wait to see future updates!

    I'm new to all this.

    in General Discussion

    Posted

    Rick is an expert in Lua and trains people in Lua, so his advice is very valuable!

     

    I'm experienced in C/C++, but I use Lua about 99% of the time with Leadwerks. It's so much simpler and quicker to get things done and tested. Waiting for your program to compile only to see seg faults appearing isn't the most pleasant thing in the world. Handling strings and other more complex objects can also be a pain. Plus, it's easy to just attach Lua scripts to entities in the editor.

     

    If you are really interested in game dev, then starting with OpenGL might be kind of tricky (which is why people buy engines in the first place). To completely understand it, you need to have a good foundation in linear algebra, a decent knowledge of GPU architecture, and an understanding of advanced programming concepts (such as precision errors).

     

    In terms of C differing from C++, C++ is somewhat a superset of C, meaning that C code will run when compiled with a C++ compiler. OpenGL being written in C shouldn't matter, but I think the reason to teach it in C is because C++ features aren't really necessary for OpenGL. You are welcome to use C++ if you want though, and it'll probably scale better as you develop a larger OpenGL program and start using a bunch of shaders and VAOs. Classes are simpler to manage that structs with function pointers imo. There are other useful features besides classes with C++, and usually compilers are a little less stringent on C++ syntax because the standard is more forgiving.

     

    BTW, what is your background in programming? Jumping straight into C/C++ isn't usually recommended for beginners.

    • Upvote 1

    How would you store a grid-based map?

    in Programming

    Posted

    EDIT: Sorry Rick! I keep responding while you're responding!

     

    Yes, I changed my mind quite a bit regarding this and thanks for explanations and advices, Nick! Also, there would have been only 6 directions because each cell has 6 neighbors (it's a 2d grid and when calculating the path, the neighbors of neighbors would have been accessed with gridCell->left->topLeft or gridCell = gridCell->left; gridCell->topLeft;).

    Oh, sorry. I misread that! You can still use an array without pointers though for an n x m matrix. It's relatively trivial to do. Every odd row could have m-1 elements, whereas each even row would have m elements. Just make a macro function (to avoid a function call) for each depending on the row, for example:

    • topLeft=[n-1,m-1] for even row, [n-1,m] for odd row
    • left=[n,m-1] for both

    PS: Right now, my project actually uses Djikstra to calculate the shortest path on a smaller matrix (21*21 -> since the party can travel maximum 10 squares in any direction until they run off stamina and diagonal travel costs 1.5x straight travel stamina). Do you have a suggestion what to use instead of that?

     

    Yeah, use A*. If you have a destination in mind, then A* will be faster because you use a heuristic to first estimate the shortest path and then actually do the calculations. Djikstra just computes everything in the area, which is very inefficient.

     

    PPS: Also, I am using the ForEachVisibleEntityDo() function each frame to update animations for characters visible on the screen (current camera). Possibly not a good idea because only characters have animations. Any ideas?

     

    I would hope that the view frustum culling is done before sending data to the GPU. If that is the case, you will be gaining nothing by animating like that, and it would even hurt performance (not by much though) if the characters already have scripts. You should just animate in the character's script.

    • Upvote 2

    How would you store a grid-based map?

    in Programming

    Posted

    Don't use Djikstra's. That algorithm is good for some things, but pathfinding in games is not one of them. It'll be way too slow. The run time complexities are of different magnitudes.

     

    A 35% use rate is not enough to warrant a sparse matrix imo. If you are concerned with space, these can help:

    • Avoid a Vec3 in the struct. Use floats instead or make another struct of floats. The Vec3 class has a bunch of overhead.
    • Storing pointers is worse than storing a 3D array. The array gives you neighbors automatically, but adding up to 26 pointers to cover all directions will cost you more. It looks like you are using a pointer graph rather than an adjacency list.0

    Space for storing graph the way you are doing:

    • 0.35 * 25,000 * (12 bytes for position + 26 * 8 byte addresses on a 64-bit machine) = 1.8 MB

    Space with just a 3D array:

    • 1.0 * 25,000 * (6 levels) = 0.143 MB

    That's a huge difference in savings! Of course, if you have too much extra information per struct, you could just have a pointer to another struct of class with extra information.

     

    Also, using a bunch of pointers the way you are using them is bad for spacial locality, meaning that you are going to be getting a lot more cache misses, so it could slow down your program. You also would have to deference a bunch of objects which would cause even more memory lookups.

     

    In the future, other possible solutions could be to have pointers between levels, so it would be a 1D array of 2D arrays. This could be useful if each level is a different size.

    • Upvote 1

    Deferred renderer

    in General Discussion

    Posted

    I know there aren't shadows. BTW, I don't think Minecraft does shadow rendering or lighting at all. It seems to use some sort of neighborhood analysis (kind of like SSAO) to determine the lighting, which is really cheap.

     

    I thought each box was an entity until i reread your description. That means you have 256 unique entities though. That's a lot of unique entities. It's possible every frame 256 entities are coming from CPU to the GPU. You're going to run out of bandwidth at a certain point by doing that since you aren't taking advantage of instancing.

     

    I might not be right on this being the issue though.

    Deferred renderer

    in General Discussion

    Posted

    Ok I see what you are doing. If you are using that many entities, I think you are going to have performance issues regardless. Also, I wouldn't consider 150 FPS low, especially for this type of scene. I mean, you are using a huge number of blocks and still getting that framerate. It would probably be the shadows that cause the biggest slowdown.

    Deferred renderer

    in General Discussion

    Posted

    No, that's how the renderer is built. More geometry is actually what deferred renderers are good at computing. That, and a lot of lights.

     

    Deferred renders perform poorly on weak hardware because of the amount of VRAM they use. In fact, the time complexity of a deferred renderer is fairly good in comparison with forward rendering:

    http://gamedevelopment.tutsplus.com/articles/forward-rendering-vs-deferred-rendering--gamedev-12342

     

    Actually, on second thought, you can kind of turn off the deferred renderer, but you can't disable the render targets, so I don't think you would get any performance gain unless the lighting shader is poorly optimized.

    • Upvote 1

    CharacterPhysics, change size of the controller

    in Programming

    Posted

    Hitboxes are unrelated. You would literally just make a bigger hitbox. I don't think I follow.

     

    If you are talking about the physics shape of the character controller, there are a few things you could do. One is to attach a physics shape to the controller, but this might get glitchy. Also, if it is larger than before, then the character won't be able to use pathfinding easily. You could make your own pathfinding solution, but that can be challenging if you are new to programming.

    CharacterPhysics, change size of the controller

    in Programming

    Posted

    Yeah you can put it in crouch mode as a cassius said. But that's about it.

     

    Let's say you have a door frame in a game. The character controller might be around 6 feet. If you have a monster that was 12 feet tall, then how do you compute the navmesh? Do you choose the largest controller? What if you want the player to be able to hide or go through smaller areas? That's the problem with this. You could make the argument though that the navmesh be generated like it is now and then have the developer deal with it.

    Improving Tesselation Resolution

    in Game Artwork

    Posted

    Thanks! Those tutorials you wrote are super helpful! I kind of wish I saw them earlier because those are some of the best tutorials I've seen on the subject.

     

    Btw, I actually got it working yesterday. I guess I thought there was more control you could have over the shaders than just the number of subdivisions you could have and how you want the subdivisions to behave (to an extent). I was able to make shattering windows because of it lol.

    • Upvote 1
Copyright © 2024 Ultra Software.
All rights reserved.
×
×
  • Create New...