AWS Thinkbox Discussion Forums

IMaxKrakatoaPRTSource feedback

I finally got an implementation working. I’m still tweaking it so I’m not sure how well it will perform once I get it up to the spec I designed.

  • Pain to code. Since I don’t have a file yet I have to emulate one? And just guess the reading pattern? Maybe this is just my shortcoming of not wanting to code in vanilla “c” with pointers and memcpy. I prefer type-checking and objects.

  • I wasn’t expecting it to read one particle at a time. I can imagine this being pretty inefficient. My code is fully multithreaded. and since you sort anyway, there is no need to block or sync. Why not give a few MB of buffer to fill.

  • I don’t see a difference between negative particle counts. Is this just some malloc on your side? All in all I’m estimating two to five unnecessary copies involved

That’s all for now.
I’m testing for speed next week to see if this will work in production.

Ben.

Also, I’m not seeing the results in the render, just the viewport. I just want to make sure that prt sources are being included in the render filter. You know, before I go insane looking for bugs in my code. :smiley:

B.

I’m using Krakatoa 1.6.1.44127 and PRT Source particles appear as expected in the render. They’re affected by the “PRT Loaders” toggle.

(When I get a black frame, it’s usually because I forgot to add a light.)

I do have a light. I made a prt volume to sit beside it. Nothing shows up in the alpha or color channel. but the prt coume works fine. I have build 1.6.1.43756 , I can’t seem to find anything newer to download that isn’t a broken link.

Loading 1 particle at a time will be the more difficult issue to deal with once I get it to render.
Ben.

You can get the 1.6.1.44127 from the Krakatoa downloads page: thinkboxsoftware.com/krakatoa-downloads/ The bug you are seeing was fixed in that build.

Ok, had a bug in my density channel. thats why nothing would render. So far it’s looking good. I’m trying to find a way to auto-detect that krakatoa is the renderer and that geo-verts is not enabled so I don’t waste calculations building the mesh of the object designed for the other renderers.

Performance is decent so far, and might only be a fraction of overhead making so many tiny read calls. I need to multi-thread the particle creation part on my side with the minimum about of blocking on the read calls.

FranticParticles.GetBoolProperty "RenderGeometryVertices"

Would be the MAXScript call to determine if geometry vertices are rendering as particles. FranticParticles is a global singleton that will forward to the current renderer if it is Krakatoa, otherwise you’ll get an exception.

Privacy | Site terms | Cookie preferences