Hi,
I’m just trying to implement motionblur.
How is motionblur calculated? And how do I calculate motionblur in my particle stream? If I generate a particle, how do I know at which time the position is needed?
And another question:
Is there a way to modify the particle radius? At the moment I need a very high amount of particles to get a useful rendering where less particles with a larger radius would be enough.
Just implemented particle multiplication.
My particles render fine with a normal rendering.
Unfortunatly as soon as I try to use it:
ParticleStream *stream = &this->mtk_particleStreamList[0];
krakatoasr::particle_stream ps = krakatoasr::particle_stream::create_from_particle_stream_interface(stream);
add_particle_stream( ps );
if( stream->renderUseMultiRadius)
{
add_particle_multiplication(ps, stream->renderMultiRadius, stream->renderMultiSubdivs, stream->renderMultiPPSubdiv, stream->renderMultiDensityFallOffStart);
}The resulting image is completly black. The values I used are:
multiRadius = 0.1
subdivs = 3
particlesPerSubdiv = 10
falloff = 0.0
For my particle object with approximatly 10 units(cm in maya) in diameter.
I can see the message:
Computing particle multiplication grid.
But that’s all. The smaller the radius, the more memory is needed and the longer the calculation takes, but the result is still black. Any ideas?
This was from quite some time ago, but I tested this out. A stream that returns zero particles (for particle_count) does not throw an exception for me. What are you returning on get_next_particle (it should be always be false if there are zero particles). Is there maybe something else going on?
If you are creating your own particles using a custom particle_stream_interface:
-Particle “Positions” channel values must represent the position of the particle at the zero shutter time.
-Motion blur is calculated from the “Velocity” channel values. Velocity is in scene-units per second.
For example:
Given a scene that has motion blur shutter times -0.008 to 0.008 (begin/end in seconds… this would represent centered motion blur with around a 180 degree shutter at 30 fps)
a single particle at position [0,0,0] with velocity [2,0,0] (particle moving two units per second in the x direction)
During the render, that particle will be “smeared” from position: [-0.016, 0, 0] to [0.016, 0, 0]
Particles in Krakatoa don’t have any volume. They just exist as a point samples. You may be able to get the look you’re looking for using particle multiplication, or by increasing the size of the “draw point filter”.
I believe this should work if you call “add_particle_multiplication” prior to calling “add_particle_stream( ps )”. Does that work for you then?
Second question: You say that it’s a black render, but how many particles is the renderer reporting that it is rendering? Is it zero?
Thanks for your answers, I’ll try our suggestions and report the result here.
The particle count seems not to be zero, but I’ll have to check again.
There is a little bit of confusion. The “zero particles” response was a response to “arun” from a previous post, not in regards to your question.
If I add the
add_particle_multiplication
before adding the particle stream, it works fine. I have to be careful with the number of subdivisions and particles but it is cool!
edit:
And motion blur works as well.
Hi,
create_from_particle_stream_interface() is crashing for me when I provide a particle_stream_interface with zero particles AND zero channels (never even called append_channel()), which doesn’t make sense of course, but if create_from_particle_stream_interface() throws an exception we could catch this in any case. Sorry for the confusion.
Ok, I’ll try to see what the issue is. Thanks for the report!
Also thank you very much for adding the cancel callback to the renderer. Arun implemented it and I tried it when rendering a few million particles. It is working fine, however, I noticed that in some cases a lot of memory didn’t get cleared up. So I added a simple cancel callback to the example posted here and it seems like it is only leaking memory when cancelling in the middle of the lighting or rendering step.
Thanks,
Sven
Oh, that’s a bad sign. I’ll try to find out what memory is not being cleaned up. That is a pretty bad one, thanks for letting me know.
HI Conrad,
We’re trying to calibrate the output from Krakatoa SR with outputs from a opengl renderer (given same particle scattering/emission and lights). The thing is the output from Krakatoa always seemed dim by a factor of about 15. So if I spike up the light intensity, it matches the output from a opengl renderer.
In my test render I had a particle with density 1 and color(0.5,0.5, 1) be lit by a point light with intensity (1,1,1). The camera was real close to the particle that it filled an entire pixel. The output I got was (0.04, 0.04, 0.08) while I was expecting (0.5, 0.5, 1).
Then we noticed this comment on the light’s set_flux API that
.
Why does this default to 12.5, shouldn’t it be 1. Spiking up the light intensity to 12.5 did fix the output and I got my expected output (0.5, 0.5, 1).
thanks
Actually, I missed out one detail in my previous post. The light was set to have to “no decay”. When I enable decay (linear or quadratic), the outputs go out of sync again, with opengl output.
Does the fact that the default light intensity should be 12.5 have something to do with this.
thanks
This was originally designed to be specified in real photometric units of flux density. The 12.5 is approximately 4pi. So, if you multiply your input value by 4pi, does it match?
Do you mean multiplying the input color value by 4*pi. Yes that does fix the issue, so now the light decay also works consistently. Thanks for the suggestion.
I have another issue, this one about the cancelling API. When I turn on Depth of field and the renderer enters the “Drawing # particles” stage, it stops querying the canceller for cancel events for a long time. It feels like it is almost at the end of this stage when it queries again and cancels out. The “drawing particles” step typically takes the longest time, when DOF is on and the user is most likely to cancel the render at this point. But since the render doesn’t query the API, it doesn’t cancel out immediately. Can this be fixed. thanks
I’ll take a look at adding more cancel checks in the drawing stage. Thanks for the suggestion!
HI Conrad,
I think we may have ran into a memory corruption/freeing issue inside the KrakatoaSR renderer. The problem is happens when we mix-match channels with different data-types (of different sizes) inside a particle.
I noticed the problem started when I had float16 in my particle source like:
Position : float32x3;
Color: float16x3;
Density: float16x1;
If I replace all the float16s with 32-bit values the problem goes away. Additionally it was also fine when I terminate the structure (the last channel in this case) with a 32-bit value like:
Position : float32x3;
Color: float16x3;
Density: float32x1;
Here’s the walkback we got:
[code] ntdll.dll!RtlpBreakPointHeap () Unknown
ntdll.dll!RtlpCheckBusyBlockTail () Unknown
ntdll.dll!string "Enabling heap debug options\n" () Unknown
ntdll.dll!RtlDebugFreeHeap () Unknown
ntdll.dll!string "Enabling heap debug options\n" () Unknown
ntdll.dll!RtlFreeHeap () Unknown
kernel32.dll!HeapFree () Unknown
msvcr90.dll!free(void * pBlock) Line 110 C
KrakatoaSR.dll!krakatoasr::particle_stream_interface::get_channel_value() + 1414 bytes Unknown
KrakatoaSR.dll!krakatoasr::particle_stream_interface::get_channel_value() + 1316 bytes Unknown
KrakatoaSR.dll!000007fee689c117() Unknown
KrakatoaSR.dll!krakatoasr::particle_stream::~particle_stream() + 116 bytes Unknown
KrakatoaSR.dll!krakatoasr::krakatoa_renderer::reset_renderer() + 4002 bytes Unknown
KrakatoaSR.dll!000007fee68b8bda() Unknown
KrakatoaSR.dll!krakatoasr::krakatoa_renderer::render() + 329 bytes Unknown[/code]
This walkback was generated from inside eyeon Fusion 6.4. Sven, from my team, managed to crash it using float16 types in a standalone app. I’ve attached a copy of the file. I can attach the entire dir with the visual studio setup, if needed.
I believe this may have something to do with data alignment as suggested in :
http://stackoverflow.com/questions/119123/why-isnt-sizeof-for-a-struct-equal-to-the-sum-of-sizeof-of-each-member
However, one typically needs to know the struct type in advance and then assume the wrong size (by accumulating data member sizes). Not sure how krakatoa can get into this issue, since you guys don’t know what the particle type is.
Let me know if you need any other information, or help replicating this.
thanks
arun
Test.cpp (12.7 KB)