float dist = g_xWorld_VoxelRadianceDataSize 2;
float3 startPos = P + N g_xWorld_VoxelRadianceDataSize * 2; https://github.com/turanszkij/WickedEngine/blob/master/WickedEngine/voxelConeTracingHF.hlsli#L40
float3 startPos = P + N g_xWorld_VoxelRadianceDataSize * 2; https://github.com/turanszkij/WickedEngine/blob/master/WickedEngine/voxelConeTracingHF.hlsli#L40
You will calculate the position of the first iteration as: tc = startPos + coneDirection * dist; having both an offset in startPos and dist?
@matt77hias Hi Matthias, as you can see I'm offsetting once by surface normal and once again by cone direction. The offset by surface normal is required because I don't want to include the surface's own voxel in the tracing. Then I also step away in the cone direction initially, because I don't want each cone to start at the same voxel (but linear filtering can pull samples from that voxel so it's not entirely skipped). Also, stepping a single voxel along surface normal is not enough by itself, because diagonal rays can still hit the self-voxel, so it also helps a bit in that case. The multiply size by 2 is as you know because my default voxel size is 2 world space units, something I will fix or document better sometime. The step sizes probably require some more tweaks though as well as cone aperture sizes for different cone counts, etc.
@Kenji245 Hi, no plans I'm afraid, but good idea, I'll think about it. I want to at least include a bigger lua script demo than the current one. I have made a basic third person character controller/dungeon generator in lua previously, but needs to be updated before I include it. Thanks for feedback!
@Kenji245 I'm afraid there is nothing of a more advanced system in place yet, this is it, you can load text files with wiLua::RunFile("myFile.lua"). You can also run a file from a lua script by calling doFile("myFile.lua") from a lua script. You can also load a string from a C++ file by wiLua::RunText("myLoaCommands as text")
@Kenji245 Also, on application load, startup.lua file is called as a script if the file itself is found in the app working directory. And from a lua script you can immediately access the "main component" as main which has a few functions to control application state. Application state change could be something like calling main.SetActiveComponent(myGameComponent). The idea is that for example a main menu could be a game component like a Renderable2DComponent, and game could be DeferredRenderableComponent for instance and the MainComponent can switch between them. Sorry that it is not well documented yet...
Was looking for something in "Interactive Indirect Illumination Using Voxel Cone Tracing" and noticed the color blend formula c :=
αc + (1 − α)α2c2. Isn't the α2 missing from your blend formula https://turanszkij.wordpress.com/2017/08/30/voxel-based-global-illumination/? For example an initial sample of [1,1,1,Ɛ], while marching, currently contributes [1,1,1] as opposed to [Ɛ,Ɛ,Ɛ]? Though, I assume the effect is small in typical scenes, since the low alpha values are contained in the coarse mip levels and the fully transparent cells which already have a color of [0,0,0].
αc + (1 − α)α2c2. Isn't the α2 missing from your blend formula https://turanszkij.wordpress.com/2017/08/30/voxel-based-global-illumination/? For example an initial sample of [1,1,1,Ɛ], while marching, currently contributes [1,1,1] as opposed to [Ɛ,Ɛ,Ɛ]? Though, I assume the effect is small in typical scenes, since the low alpha values are contained in the coarse mip levels and the fully transparent cells which already have a color of [0,0,0].
Ahh, I don't have the time to look into this now, sorry. Have to finish the cpu-side rewrite, it is already taking too long. The current state of Voxel GI definitely can be improved and I am still slightly interested, and there are even more interesting things such as solid voxelization, anisotropic voxelization, voxel cascades. Though pure raytracing is much more satisfying and interesting these days, in my opinion. :)
wiECS.h's ComponentManager uses a separate collection of entities (32 bit values) and components. Sorting the latter requires sorting the former and updating the lookup table as well. I wonder if the gain of decoupling the entities from the components for processing outweighs the bookkeeping? I mean if you add the entity to each component, what would the performance drop be? Or is there another reason?
*Other reason for the decoupling
Was working on something similar to allow reordering the components. If a multi iterator which wraps multiple iterators would be compliant with the std, all the std algorithms could be used and everything would be transparent (ComponentManager could be implemented as a separable map for instance). Unfortunately, pairing iterators is not supported for operator*, operator->, operator[] :-( )
Good insight! That was the first way I did it, to include the entity ID in components (as component being a "base class" of sort that must always include entity ID). But I don't like that way because most of the time ideally I only want to access a component. I want a component to be as light weight as possible, what if I really just need a component which is just 8 bits? Then having an extra 32 bits always loaded would be very heavy. Sorting is not something that is done very frequently (really right now I only do sorting on the hierarchy components whenever I attach or detach), so I don't think it's important to optimize for that instead and lose flexibility. Also, when I only want to look up an entity ID, it's also more light weight. I sometimes do this just to see if an entity contains a specific component or not.
As for the other part, most of the time I'd like to avoid overloading operators and doing fully std compliant solution. Even though I slipped in a operator[] anyway to access components…
I also assume that the transformation is retrieved the most some_component --> entity --> transform_component (e.g., for populating some model buffer).
I also have some slight incoherent questions about different aspects, if you don't mind me asking all of them :-)
1) If you kill an entity, you need to access all component managers (engine-defined and user-defined), right?
2) One aspect which keeps me puzzling is enabling/disabling an entity/component. You don't want to destroy and re-create these, but still want to keep them around, but that also means that each entity and component can be possibly disabled during some update cycle. A separate component for such state creates too many indirections since every component operation needs to check. Any thoughts on enabling/disabling?
3) Is it still beneficial to do skinning only once per frame? As far as I understand, skinning only differs with regard to the VS. Pre-computing the skinning once per frame consumes memory while still requiring some basic VS for shadowing, lighting, etc. (memory consumption vs memory accesses)?
Yes, for example if you see the serialization, you have to do special consideration for entities for several reasons, so it is also better to keep them separated, so if you would have custom constructors for components, they wouldn't interfere and less error prone.
Transform component can be retrieved as you said, however it is generally better to avoid the map lookup when querying a component manager by entity. Usually I aim to do it once per frame, so mesh instances would receive an index for their transform component, or just copy the transform component into them in some other cases. Then I can do several render passes, and no need for map lookups any more, only direct indexing.
Transform component can be retrieved as you said, however it is generally better to avoid the map lookup when querying a component manager by entity. Usually I aim to do it once per frame, so mesh instances would receive an index for their transform component, or just copy the transform component into them in some other cases. Then I can do several render passes, and no need for map lookups any more, only direct indexing.
1) Yes, you have to do it, but you can make a system that takes care of that. A system in my opinion is just a function that takes the ComponentManagers that it operates on as arguments.
2) What about having a boolean in the component indicating if it is enabled/disabled? It seems like it is just a specialized behaviour, not needed for every type of component. Better yet, to avoid booleans in structs (because of alignment issues), and have bitfields with packed booleans in them. It even makes it easier to serialize and keep backwards and forward compatibility
3) I still prefer skinning in compute shader. Sure you have increased memory requirements, but several benefits too:
- vertex shader permutations vastly simplified
- Also use skinned meshes to spawn particles from
- reuse skinned meshes across several render passes or even frames
- use async compute
So with regard to the meshes, you have some extra intermediate set of components which more directly map to GPU buffers? E.g., transform, mesh, material are separate components which are merged in some fourth component per frame that can be directly mapped to a constant buffer (or just populate the buffers directly without storing these intermediates)?
You're right about the boolean, it should indeed be some elementary operation that should be part of specific component interfaces.
For the skinning, you'll indeed have some extra VS but are the permutations that large for VSs (not sure, though, how many different vertex layouts you handle)? You can indeed reuse the data, but these data is passed to the regular VS which still requires a certain number of cycles for each render pass? The particle benefit is a nice feature, but I guess SO can handle that as well? Anyway thanks for the feedback, animation stuff is not for very soon yet :D
Right now, I have the GPUBuffers as part of the MeshComponent and MaterialComponent which are used when rendering the scene. Then the renderer assembles a render queue which is just direct indices to ObjectComponents (which are the mesh instances, kind of a stupid name, but I got used to it) and MeshComponents. Then the renderqueue gets sorted by meshIndex and distance to camera, and the nice thing is that it only sorts indices which directly index into ComponentManagers (these not change after the Scene::Update has been called, so indexing directly is safe for one frame).
For skinning, permutations might not be huge, but still very much easier to manage without a complicated shader build system and one person only. Kind of why I don't have tangent vertex buffers too. The skinning data is not passed to any vertex shader, they just swap the unskinned vertex buffers with the animated ones. Streamout can handle skinning, but the API is clunky and inefficient as it is a geometry shader extension (even if you have it as part of vertex shader, you still compile it as GS as far as I can remember). Then StreamOut stage has ordering requirements which make it less efficient than Compute Shaders. Also, you can use groupshared memory in CS which I also use for skinning.
You can take a look at wiRenderer::RenderMeshes() in wiRenderer.cpp if you are interested. This function is doing instanced draw calls. The renderqueue is a list of (meshindex, instanceindex) sorted by meshindex. It maps a big gpu buffer, then copies the instance matrices (by indexing into transform component manager) into it. After that it loops through the meshes and calls DrawIndexedInstanced for each and offsetting into the instance buffer.
I'll just link that function here: https://github.com/turanszkij/WickedEngine/blob/master/WickedEngine/wiRenderer.cpp#L1343