jcabeleira

Members
  • Content count

    244
  • Joined

  • Last visited

Community Reputation

723 Good

About jcabeleira

  • Rank
    Member
  1. Critical errors in CryEngine V code

    I agree with @Xai, these articles are clearly created for advertisement and therefore should be identified as such or not allowed at all. The tone used in these articles is not constructive. It serves little in terms of knowledge sharing and harms the authors of the analysed code in order to advertise a product.
  2. Hybrid Frustum Traced Shadows

    So, basically this technique is only useful to render shadows cast by solid geometry. Shadows for alpha tested vegetation and alike is a "no go" with this technique, right?
  3. Hey guys,   While wandering through the internet I've found an interesting 3D engine called Aurora which is apparently used in professional flight simulators. What strikes me the most is the amazing quality and the rendering which is well above most 3D engines we know. It clearly uses state of the art techniques such as physically based rendering, cloud light scattering, atmosphere light scattering, water rendering, etc that we usually only see in very technically advanced games.   If you're curious about what I'm talking about then check the following video (I fast forwarded to the best part): https://youtu.be/x6VEuaobt3A?t=113   This engine clearly took some serious development time and skills to make. And although I know the aviation industry (particularly the military one) involves a lot of money, I still think it's curious how they were able to find the people with the skills to do it. I'd like to hear your opinions about this engine. If anyone knows where this engine came from, what techniques it uses, etc then please let me know.     There are also other videos apparently from previous versions of the engine. The rendering quality is inferior but still very decent: https://www.youtube.com/watch?v=oq2O01u3MM4 https://www.youtube.com/watch?v=m-689aRRV5Q    
  4. That’s what NVidia wants you to think. In fact, it only works on NVidia because their drivers let you get away with more than they should. L. Spiro     I'd say that the truth is nearer to somewhere in-between the two.     You're absolutelly correct, it's a bit of both. I don't want to turn this thread into an NVIDIA vs AMD discussion so I'll be brief: The demo was originally coded an tested on an NVIDIA. Later, I re-tested it on an AMD and concluded that I was doing a few things I shouldn't which NVIDIA drivers let me get away with. After these issues were fixed I expected the demo to run but instead stumbled at a bug on the AMD driver implementation of Shader Buffer Objects. The problem was discussed in this thread at opengl.org.  This is why the demo has no compatibility whatsoever for AMD boards, their support for new OpenGL extensions was so bad at the time that I didn't even bothered applying the corrections I made (to remove weird NVIDIA stuff) to the demo that is available for download. All this was about 1 year ago, AMD has probably released new drivers in the meantime and maybe they have already fixed the problem.
  5. Looks very good, do you have a video or realtime download somewhere?     Thank you, you can find both the video and demo here http://www.voltaico.net/gamesdemos.html.   I hope you can run the demo since it has strict hardware requirements, it needs an Nvidia GTX 680 or above. Unfortunately it won't run on AMD cards due to their buggy drivers.
  6. Here is the result of sweat and tears. It's my pride and joy!   
  7. Dijsktra and STL Priority Queues

      Many thanks, I followed your advice and implemented a binary heap myself and I got nice results. My custom heap allows to update existing items which is very convenient for pathfinding and gives a big performance boost in comparison to STL containers which cannot update items (forcing me to remove items and re-insert items just to re-sort them). I definitely recommend using a custom well implemented priority queue for pathfinding if performance is important.
  8.   The problem is computation and memory cost go up quite quickly with increased voxel resolution, and he's only getting that with a small room. Ideally you'd have say, a 16 square kilometer grid centered around the player. Which is going to cost more than enough by itself, without getting into the same voxel resolution as screen resolution.     Screen space effects are still useful for voxel cone tracing because the voxels often don't have enough resolution to provide finner details. For instance, ambient occlusion generated naturally by the cone tracing tends to look a bit washed out due to the lack of geometric detail and thus can benefit from SSAO to give finner details. Same thing goes for reflections, if you want sharp reflections you'd need very small voxels which is impractical and expensive, in this case screen space reflections can help a lot. However, for blurred reflections voxel cone tracing is very good.
  9. Dijsktra and STL Priority Queues

    Thank you all for your answers, things are getting clearer now.         I've tried it and it works fine, thank you! There is one more issue though, imagine this: - Node1 is already in the queue with a shortest cost of 3 - During the graph exploration I find a new shortest path to Node1 with cost 2 - So I insert Node1 into the queue with the new cost of 2   Won't this create a duplicate entry of Node1 on the queue, where the first entry as a cost of 3 and the second entry has a cost of 2? Is there an easy way to update the existing entry on the queue and re-sort the queue?
  10. Hello guys,   I'm implementing Dijkstra and I have a question regarding the priority queues. Most people use one of the STL queues to store their list of nodes to be visited. However it seems that these queues (std::set, std::make_queue, etc) don't allow to store two or more nodes that have the same exact distance to the start node. Take this example:            Start Node-----3-----Node1                 |                 3                 |              Node2   As you can seen both Node1 and Node2 have the same distance of 3 to the start node so when exploring the start node you would insert both Node1 and Node2 into the queue. However the insertion of the second node will fail because the priority queue already has a node with shortest distance = 3. Can someone confirm this observation is true?   I've seen my implementation fail to find the shortest path because of this fact. It is a rare phenomenon because it is not probable that two nodes have the exact same distance but it does happen and when it does the algorithm fails completely.   Thanks in advance
  11.   -Why do you multiply by 1/6? -Where is the light color?     The functions in the volume are spherical harmonics that represent radiance (energy flowing through space) and what you need for rendering is irradiance (incoming radiance at a point). To do that you sample the spherical harmonics using the surface normal as sampling vector and a set of special coefficients where these coefficients represent the hemisphere above the point being processed, in particular they represent the cosine convolution of that hemisphere. The area of the pixel doesn't play an important role here and it can be ignored.     BTW, please forgive my honesty but I think you're paying too much attention to the theoretical details and forgetting that the whole technique is a huge hack so mathematical correctness won't bring you the benefits you expect. There are several limitations that jeopardize your mathematical accuracy such as the low resolution of the LPV, the low resolution of the spherical harmonics (not enough bands), the limited propagation distance, the poor blocking of light, the limited bounces, etc. etc. In the end you'll probably need to disregard mathematical correctness and hand tune the effect to achieve better practical results (just like Crytek itself did).
  12. Another reason for the transparency is that you are sampling the voxels along the view ray but none of the samples hits the exact center of an opaque voxel so they never achieve full opacity. This is because the voxel volume texture is configured to use bilinear filtering so whenever you sample an opaque voxel without hitting its center you get a partially transparent result that is the interpolation between the opaque voxel and the neighboring transparent ones.
  13. Global illumination techniques

      You're right, I didn't know they used light probes like that. It's a neat trick, useful when you want to give GI to some key areas of the scene. 
  14.   They don't have any flickering because the octree allows them to store the entire voxelized scene. Their lighting is stable because they don't need to have a moving voxel volume that only covers the scene partially. However, the octree is probably impractical for many games because larger scenes may not fit inside the 512x512x512 texture they use to store the voxel bricks.
  15. Global illumination techniques

      Environment probes do not work like deferred lights. They are points in the scene where you calculate the incoming lighting in a pre-processing step. In runtime, you apply them to an object by finding the nearest probes to that object and interpolate between them accordingly. If I'm not mistaken this is usually done in a forward rendering pass because you need to find which are the nearest probes to the object and pass them to the shader.         A 1x1x1 cubemap will give you a very poor irradiance representation, you'll you need more resolution than that. And yes, you can use the lower mipmaps of the specular cubemap to approximate diffuse but once again the quality will be poor. The best way is to generate a cubemap for diffuse with a diffuse convolution and a separate cubemap with higher resolution for specular generated with a specular convolution. The mipmaps of the specular map can then be sampled to approximate different specular roughness as you said.