-
Posts
853 -
Joined
-
Last visited
Content Type
Blogs
Forums
Store
Gallery
Videos
Posts posted by klepto2
-
-
I know that i can render to a texture, but i want to run the Vulkan Pipeline without using a window like this:
#include "UltraEngine.h" using namespace UltraEngine; void RenderHook(const UltraEngine::Render::VkRenderer& renderer, shared_ptr<Object> extra) { Print("RENDER_HOOK called..."); } void TransferHook(const UltraEngine::Render::VkRenderer& renderer, shared_ptr<Object> extra) { Print("TRANSFER_HOOK called..."); } int main(int argc, const char* argv[]) { auto cl = ParseCommandLine(argc, argv); EngineSettings settings{}; settings.asyncrender = false; //Create a world auto world = CreateWorld(); //Create a framebuffer auto framebuffer = CreateTextureBuffer(512,512); auto camera = CreateCamera(world); world->AddHook(HOOKID_TRANSFER, TransferHook, world, true); world->AddHook(HOOKID_RENDER, RenderHook, world, true); //Main loop for (int frame = 0; frame < 100; frame++) { world->Update(); world->Render(framebuffer); //camera->Render(); } return 0; }
but this leads to an assert error at world->Render(), one solution is to create a hidden window, but it would be nicer if it would work even without the need of a window and a correct framebuffer.
-
You requested a feature for my IBl Generator, while i have managed to get it to work as a cli, i still need a Hidden window to get all the work done.
As far as I know vulkan is allowing headless rendering for this, where you don't need an actual surface.
https://github.com/SaschaWillems/Vulkan/blob/master/examples/renderheadless/renderheadless.cpp
It would be nice to have the ability to create a Framebuffer without having a window.
-
To limit the confusion for users, you might consider to add a small info where the Material selection would be, which states something like:
"No Terrain selected"
-
I promote this suggestion because:
In the latest weeks you made a great progress with the editor, but while testing the editor with lots of files i found some things which could be made easier if a small clear cache function is integrated: Also this function is more or less a very easy one to implemnt.
- In the latest updates you suggested multiple times to delete the thumbnail folder
- The overall cache can grow extremely in size and to easily clean it up from the editor would be handy
- the clear cache should be optionally global or per project
- 1
-
Fixed the blurriness:
The color is not as bright as the one from the ibl sampler as it uses dds or tex files to gnerate the filtered cubemap, which is different to the hdr format. Maybe i can find a soltuin for that as well.
- 1
-
The code is the same as the one from Khronos. What might be, is that I have one step missed. But the mipmaps are generated the same way. And before downloading they look smooth. But will take a closer look.
- 1
-
this might be due the type of host synchronization i do. I currently use vkCmdCopyImage which doesn't support linaer filtering for the download. I will later try to change it to staging buffers, which might be better in this case.
-
The Zone-map with the provided zone-sky only.
the generated specular and diffuse maps in action
this is a current screen of the tool with the settings used:
-
It is saving the dds file with the wrong mipmap count, but it will not load in ultraEngine, while other tools load it, but display a black screen.
-
Ok, found the error. I generated to many mipmaps. BCH6 has a blocksize of 4 which i missed, which means the lowest mipmap size is also 4 and not 1.
Thanks for the point in the right direction.
-
2 hours ago, Josh said:
The asset browser actually does not use Vulkan for rendering. Rather, it loads the texture as a pixmap and converts the pixel format to BGRA, then displays it on a panel as a pixmap.
It would be helpful to get the cubemap you saved, because otherwise I am not sure what I am looking for. There are several possible points of failure:
- The saved cubemap might really be black
- Loading a pixmap from a cubemap might not be working
- Converting the cubemaps's pixel format to BGRA might not be working
The saved cubemap is black, the pixmaps in the mipchain passed to the save texture function are valid. They are saved correctly, when the pixmap save method is used. Just the provided way in the blog sample and the sample itself is not working. If you still need some data i will provide it later.
The cubemap data is calculated in a computeshader and the result is mapped back to the host. For the later atmosphere shader I just need the calculations, but for the engine I thought I could provide a small tool which also saves the generated cubemaps. I know iblsampler, and I use some shader code from it.
-
The reason why cubemaps are not shown in the asset browser is, that the pbr shaders don't support cubemaps as diffuse texture. You can try it yourself and create a material and try to assign a cubemap to the diffuse slot. In this case SaveTexture just saves black color instead of the actual pixel values. I know that it worked some time ago as i have tried the code mentioned in the blog before. Maybe Josh just hasn't applied some internal changes which were made lately.
Btw: yes i tried them in the Editor as well
- 1
-
the noise texture was ok, the other noise texture i use is closer to the original.
The artifacts came from this line:
p.x *= gl_FragCoord.x/buffersize.y;
this: should have been:
p.x *= buffersize.x/buffersize.y;
this line calculates the aspect ratio and if you use gl_FragCoord.x it is dependend on the pixel position which leads to the artifacts you have seen.
- 2
-
I am working on a small tool to generate the specular and diffuse maps based on an input cubemap:
While the generation itself works flawlessly, I can't get the SaveTexture feature to work with cubemaps.
I download the image data from the gpu and if i save the pixmaps (each face and mipmap) seperately this works. But with a mipchain i only get a black cube texture. (Tried it with various viewers, renderdoc, nvidia texture tools).
Then i tried the sample you provided here:
and followed the same workflow as you. The result is the same, the code in this blog also results in a black texture
- 1
-
Try this: i have added the diffuse layer, so the background is visible.
1. I changed the noise texture to the one used by shadertoy (using other textures might lead to artifacts)
2. I corrected the aspect ratio calculation you had p.x*= gl_FragCoord.x / buffersize.y; where is should be p.x*= buffersize.x / buffersize.y;
- 1
-
You can upload the pfx and textures here, and i can look at it if you want.
-
1 minute ago, havenphillip said:
@klepto2 I'm quite certain you know more about this stuff so I defer to you. I just assumed. If it was me I'd try to find a rain shader that uses noise instead of going through a script with the noise buffer.
yeah, that is what most users do with shadertoy shaders. But gpu noise is far too expansive to be used in realtime scenarios (espacially when it is a game or so) It is always better to use a noise texture than to calculate the noise with the various available noise methods for glsl.
1. Performance: noise calculation on the gpu is much (and i mean very much) slower than a simple texture lookup.
2. low end hardware: most noise mehtods have something like this:
float hash( vec2 p ) { float h = dot(p,vec2(127.1,311.7)); return fract(sin(h)*43758.5453123); }
but this will result in unexpected results on low end hardware (espacially integrated gfx)
- 2
-
But i agree, with the proper background the rain would be visible without the need of muliplication.
-
1 hour ago, havenphillip said:
Ok so you set the "col" to vec3(0,0,0) that's where the black is coming from. You're sort of just trying to add the effect over a black screen. The screencolor texture for post effect shaders is texture1. That gives you the standard screen. Set it instead to:
uniform sampler2D texture1; //color
...
vec3 col = texture(texture1, q ).xyz;
While this is true, it isn't needed in this case. The shader on shadertoy also just uses a black background, which might be what he currently wants. The blending with the actual background is not yet the problem. The problem is, that the calculated value for 'f' is just to low to be recognized in the output. a multiplication by 2.0 or 4.0 will move the rain into a more visible spectrum.
Another problem might be the pfx lua script. This would be nice to see as well to figure out if the noise texture is correctly bound.
- 2
-
Read the comment on shadertoy: change this line
fragData0=vec4(col, 1.0 );
to
fragData0=vec4(col * 4.0, 1.0 );
and you should be able to see the effect.
- 1
-
One way is to use a post effect, I can't fully reply currently, but this is a starting point:
You attach the pfx to your scene, and if you have a driectional light in the scene it will automatically find it and use the correct light vector.
- 1
- 1
-
-
Maybe just simple: provide all 3 and just make a default setting in the editor. This way the user can choose which he prefers.
-
Another option (which would be IMHO more convenient) would be to add Import and Eport menues. This way you can later support multiple map formats without breaking the original save and save as workflow.
Load/Save/Save as -> only for UltraEngine files
Import/Export -> reserved for plugins or fixed imports/exports in the engine.
Ultra Engine noob feedback thread
in General Discussion
Posted
Like Leadwerks, the Standard-Edition will support Lua, while the professional Edition will also support C++.
The Lua integration is much more advanced than in Leadwerks, More or less everything which is publicity available by the cpp api is also available in LUA. As a bonus point the Editor has a plugin system which allows simple or advanced lua scripts and cpp (dll) plugins to add functionality to the editor.