Is it really need to free memory for gdp into procedural. Smth like freeGeometry(gdp)?

Thanks

any ideas?

Wish
Is it really need to free memory for gdp into procedural. Smth like freeGeometry(gdp)?

Thanks

If you've passed that geometry on to mantra, then mantra owns it, and deleting it would be bad.

For example, if you've done something like

openGeometryObject();
addGeometry(gdp, 0);
closeObject();


If it's a temporary gdp (that mantra doesn't own), you can do something like:

delete gdp;


When your procedural's geometry is ray-traced, mantra has to hold on to the geometry. When it's rendered using micro-polygon rendering, the geometry should automatically be deleted when the bounding box of the geometry is no longer on the screen (i.e all buckets that refer to the geometry have been rendered).

I hope this helps,

Yes, Mark. Thank you!

I made a procedural but it doesn't work like point instancer. I'm trying to make it like delayed load with point instance property.
I query points into shader and then iterate them into point loop.
Bad result, memory jumps up. I want to build geometry onto points which are inside camera frustrum.

Wish
I made a procedural but it doesn't work like point instancer. I'm trying to make it like delayed load with point instance property.
I query points into shader and then iterate them into point loop.
Bad result, memory jumps up. I want to build geometry onto points which are inside camera frustrum.

Split the points into sub-sets and create new procedurals (rather than generating all geometry at once). Or generate a new procedural for each point.

Mantra can then cull the intermediate procedurals before it needs to generate geometry.

Sub-sets? What do you mean?

If a create smth like a procedural point in position of each point of template points and then generate geometry in each new procedural points, then mantra will cull those intermidiate points which doesn't belong to frustrum?
Can I do this in one procedural shader and it will work well? Or there will be 2 nested procedural shaders?

Wish
Sub-sets? What do you mean?

If a create smth like a procedural point in position of each point of template points and then generate geometry in each new procedural points, then mantra will cull those intermidiate points which doesn't belong to frustrum?
Can I do this in one procedural shader and it will work well? Or there will be 2 nested procedural shaders?

The simplest cast. If you have two points in your geometry, and
you're creating new geometry for each point (i.e. a sunflower or a car
or a tree).

If you process all points at the same time, you'll end up creating 2
sunflowers, cars or trees.

If, instead, you “split” the points into two separate procedurals, you
can generate process one point at a time.

For example, if one point is in the frustum but the other point is
outside the frustum, in the first case, you will still end up
generating both geometries since the bounding box of the entire point
set is in the frustum.

However, if you split the points up and process them individually,
mantra has an opportunity to cull the point that's off screen, since
the bounding boxes are tighter.

So, instead of calling openGeometryObject() mulitple times, you can
call openProceduralObject() and add new procedurals to the scene
(nested, yes).

Instead of

foreach point
{
openGeometryObject();
addGeometry(new ChildProcedural(parameters));
closeObject();
}


Try something like

foreach point
{
if (openProceduralObject())
{
addProcedural(new ChildProcedural(point and other parameters));
closeObject();
}
}


Where the ChildProcedural would generate the geometry for the single
point.

Hope this helps (and makes more sense).

Thanks Mark, I will try!

If there are 2 classes. Each of two have render() method. Which of render() will go out to render?
Or there is no need of 2 full proceduralready classes?

Wish
If there are 2 classes. Each of two have render() method. Which of render() will go out to render?
Or there is no need of 2 full proceduralready classes?

2 classes (I would think) would make it clearer.

The first class would be the one the user interacts with (similar to what you have now I'm guessing)

The second class would be used internally by the first procedural.

So, the first procedural gets invoked by mantra (the render() method gets called) – this is because the user wants to use it. Its render method generates a bunch of new procedurals (the 2nd type) which the user doesn't know about.

Mantra can throw some of these out, or it may call the render() method on the 2nd procedural. At this point, you would generate the geometry for a single point (not the entire geometry).

Oh. It is confusing me a little. The geometry class is a child class of VRAY_Procedural which constructor builds geometry(the first class). It's virtual method is empty.
And the second class in render() calls the first class as new object into addProcedural(the first class object);
Am I right?

Or the geometry in the first class is defined by its render method and the second class will call it by addProcedural(the first class object.render()) int its render method?

Uf… awful errors)
Houdini DSO - error on ‘/mnt/home/houdini9.5/dso/mantra/w_VRAYfeathergen.so’
/mnt/home/houdini9.5/dso/mantra/w_VRAYfeathergen.so: undefined symbol: _ZN16w_VRAYfeathergen6renderEv
mantra: Unable to find procedural DSO ‘mantra/w_VRAYfeathergen.so’
mantra: Cannot allocate procedural ‘w_feathergen’ on object /obj/geoFeatherGenerator/feathersGenerator

Wish
Oh. It is confusing me a little. The geometry class is a child class of VRAY_Procedural which constructor builds geometry(the first class). It's virtual method is empty.
And the second class in render() calls the first class as new object into addProcedural(the first class object);
Am I right?

Or the geometry in the first class is defined by its render method and the second class will call it by addProcedural(the first class object.render()) int its render method?

//Pseudo-code
class FirstProcedural {
// This class is created in the IFD
GU_Detail *myGeometry;
};

class ChildProcedural {
// This class generates a cube at a single point of the original
// geometry
ChildProcedural(UT_Vector3 &center, fpreal size)
: myCenter(center), mySize(size) {}
};

void
FirstProcedural::render()
{
int i, npoints;

// Generate new procedurals rather than geometry to render
npoints = myGeometry->points().entries();
for (i = 0; i < npoints; i++)
{
openProceduralObject(); // Create a new procedural object
UT_Vector3 center = gdp->points()(i)->getPos();
addProcedural(new ChildProcedural(center, 1.0));
closeObject();
}
}

void
ChildProcedural::render()
{
GU_Detail *geo;

// Generate the geometry to render
geo = allocateGeometry();
geo->cube(myCenter.x()-mySize, myCenter.x()+mySize, …);
openGeometryObject();
addGeometry(geo, 0);
closeObject();
}


When FirstProcedural render() is called, it will generate new
procedural objects (rather than creating geometry).

I hope this makes more sense.

It's crazy to do this for a simple box. But, if the ChildProcedural
did something more intensive, then it would make more sense.

By the way, VRAY_Procedural *allocProcedural(const char *) will define render() which wil take place into render?

Oh… and warning “ The backbone doubles back on itself”

This is timely, I was wondering how to use addProcedural().

Thanks for the info, I'll give it a try.


Mark

Ok. Mantra cull points. But the awful things happens with bboxes!!! What is the proper way of bbox generation in such situation of 2 VRAY_Proc objects?
Hehe) Points randomly culling))) Nice)

oh, Mark. One more thing. myGeometry and gdp isn't the same in your code. So, what the myGeometry is? It doesn't query any geometry and it doesn't have any point.

I've attached a working example.

The idea is that the parent procedural doesn't have to generate all the geometry at once. This allows mantra to generate geometry (and more importantly, free it), during the rendering process.