PDA

View Full Version : Adding Instances to Primitives in Layout?



RPSchmidt
02-23-2018, 08:57 AM
Hello folks!

So, I created a primitive shape plane using a null and displaced it and surfaced it in nodes.

Now I wanted to add a grass instance to the shape plane. I went to the instance tab, added the grass object, selected Surface for type, set up my random scales, etc., and set the instances for 35000.

BUT.... no instances :question:

The instancer literally says 0 instances.

Any ideas?

Thanks in advance for any help provided!

Oh, I wanted to add that radial and rectangular instances work... and Point works, but only a single instance, as expected.

prometheus
02-23-2018, 12:30 PM
Hello folks!

So, I created a primitive shape plane using a null and displaced it and surfaced it in nodes.

Now I wanted to add a grass instance to the shape plane. I went to the instance tab, added the grass object, selected Surface for type, set up my random scales, etc., and set the instances for 35000.

BUT.... no instances :question:

The instancer literally says 0 instances.

Any ideas?

Thanks in advance for any help provided!

Oh, I wanted to add that radial and rectangular instances work... and Point works, but only a single instance, as expected.
it is not possible, typicly instances requires a polygon mesh, or the use of particles, or just instanced themself .
LIMITATIONS..
Only the simple preset shapes supplied (third parties can write others)
You can't add FiberFX to primitive shapes
Cannot be used for Instancing
Slower to render if displaced
Since they are based on nulls, most "Object-level" operations won't work (such as the Object ID buffer)

jwiede
02-23-2018, 01:13 PM
They seem like they're mostly there to give basic shapes for converting into OpenVDB distance field entities. They can be surfaced as solids, but don't really appear to have "proper"/"full" geometry db entries. If you look at lwprimitive.h in the C/C++ SDK, they appear mainly intended for volumetric uses.

RPSchmidt
02-23-2018, 01:25 PM
it is not possible, typicly instances requires a polygon mesh, or the use of particles, or just instanced themself .
LIMITATIONS..
Only the simple preset shapes supplied (third parties can write others)
You can't add FiberFX to primitive shapes
Cannot be used for Instancing
Slower to render if displaced
Since they are based on nulls, most "Object-level" operations won't work (such as the Object ID buffer)

Hmm. I thought when they said "cannot be used for instancing" they meant that it couldn't be the reference object, i.e., you could not cover a mesh object with primitive instances... not that you couldn't cover a primitive with instances created from a mesh object.

Rather odd that they have the Instance tab there in the Properties.

Well, that seems to make it useless for creating terrain if I can't instance vegetation on it.

Thanks for the information, gentlemen!

jwiede
02-23-2018, 02:44 PM
Rather odd that they have the Instance tab there in the Properties.

You should report it. If those primitives cannot support instancing, then their instancing tabs (or at least the contents) should be disabled. Likewise, FFX should give an error message if user attempts to attach fibers to such primitives. Having it documented as not working (thus an established limitation), but the UI still allowing the user to trigger activation, is a nasty bug.

The user must not be able to configure the GUI to push the app into a "known non-functional" state (aka "off its rails") -- allowing that to occur basically corrupts the internal state of the app, including any user data not yet stored to disk, etc. It isn't even safe to overwrite stored user data after that, unless the app has some means of verifying that the in-memory user state is not corrupt (and LW does not*).

It's really important bugs like this that push the app "off its rails" get reported (and hopefully noticed and addressed with priority).


*: LW "internal state" necessarily includes the state of third-party plugins, and there is no SDK API support for third-party plugins to verify their own internal state (other than clearing/resetting it). That absence means there's no reliable method for LW to verify its entire "internal state", other than completely clearing/resetting to a known-good default. It's an all-or-nothing proposition: As long as any non-verified state CAN persist, then the internal state effectively remains corrupt. The only reliable fix is to get the app "back on the rails", and that requires known-good internal state.

prometheus
02-23-2018, 05:18 PM
Hmm. I thought when they said "cannot be used for instancing" they meant that it couldn't be the reference object, i.e., you could not cover a mesh object with primitive instances... not that you couldn't cover a primitive with instances created from a mesh object.

Rather odd that they have the Instance tab there in the Properties.

Well, that seems to make it useless for creating terrain if I can't instance vegetation on it.

Thanks for the information, gentlemen!

Personally my initial suspects was that trying to use a primitive shape as the surface for instancing simply can not be done, that was no surprise to me...making the primitive shape as rock boulders for instancing ..that I sort of expected it should be capable of, but it canīt even do that it seems, I was fooled when I instanced them with clone instance, itīs basicly just the same as cloning, I could also make an array of instances of them, showing up in openGL, but they will not render..so ergo, it simply doesnīt work with instances in any form, if it as a kind of volumetric primitive shape would have worked with particles or point clusters as hvīs would do, that would at least be something, but it seems this baby only just have gotten itīs head out between the legs during birth, and havenīt gotten much further out than that.

prometheus
02-24-2018, 10:51 AM
Crosspost...

If you can find a workflow of adding true polyplanes subdivided and deformed, then copy itīs displacement and use for the displacement on the primitive shape, then you could get a rough proxy object to instance other objects on, hide it from render, burt working as a preview in open gl, but....
for primitive shapes..a couple of cons.
Displacements render slowly, which sort is the whole idea of a primitive shape, they need to improve this really.
GI on the primitive shape, also slow..so you got two cloggers here.
they can not be instanced on, or used as a Instance, nor can they be used on particles nor point cluster, so it is all limited to some interesting shapes, but not very productive useful for landscape stuff with some minor exception.

It would be great if they could work out this primitive shape, to work with a proxy object, so you in essence use a subdiv plane, that is connected to the primitive shape, and if you add a deform to the proxy poly plane, the same texture is applied on the primitive shape, this means we could have a OpenGL presentation preview of the primitive shape, as well as actuall instancing object on to that proxy object, which should be invisible for rendering but instead the primitive shape is used for rendering, and the illusion of instances actually taking place on the primitive shape.
They would need to work out a connection hook that is syncing with the deform texture at the poly plane, to be in sync with size..height and all, then reacting on the primitive shape as well.

RPSchmidt
02-24-2018, 07:03 PM
Crosspost...

If you can find a workflow of adding true polyplanes subdivided and deformed, then copy itīs displacement and use for the displacement on the primitive shape, then you could get a rough proxy object to instance other objects on, hide it from render, burt working as a preview in open gl, but....
for primitive shapes..a couple of cons.
Displacements render slowly, which sort is the whole idea of a primitive shape, they need to improve this really.
GI on the primitive shape, also slow..so you got two cloggers here.
they can not be instanced on, or used as a Instance, nor can they be used on particles nor point cluster, so it is all limited to some interesting shapes, but not very productive useful for landscape stuff with some minor exception.

It would be great if they could work out this primitive shape, to work with a proxy object, so you in essence use a subdiv plane, that is connected to the primitive shape, and if you add a deform to the proxy poly plane, the same texture is applied on the primitive shape, this means we could have a OpenGL presentation preview of the primitive shape, as well as actuall instancing object on to that proxy object, which should be invisible for rendering but instead the primitive shape is used for rendering, and the illusion of instances actually taking place on the primitive shape.
They would need to work out a connection hook that is syncing with the deform texture at the poly plane, to be in sync with size..height and all, then reacting on the primitive shape as well.

I actually had excellent render time results with the primitive, even using some bumped up settings... But manipulating the scene after displacement became painfully slow.

Manipulating a deformed mesh with the same x and z (width / height) was very fast BUT rendering it with the same lighting, render settings and texture as I used on the primitive was almost twice as slow.

It really is a shame because for me, that was the primary potential I saw in the new primitives... The ability to generate massive and detailed terrain with fast render speeds even using more demanding render settings.

Hmmm. That is rather disappointing.

prometheus
02-25-2018, 04:49 AM
I actually had excellent render time results with the primitive, even using some bumped up settings... But manipulating the scene after displacement became painfully slow.

Manipulating a deformed mesh with the same x and z (width / height) was very fast BUT rendering it with the same lighting, render settings and texture as I used on the primitive was almost twice as slow.

It really is a shame because for me, that was the primary potential I saw in the new primitives... The ability to generate massive and detailed terrain with fast render speeds even using more demanding render settings.

Hmmm. That is rather disappointing.

Fast render speed, not..and I suspect the larger the item is, like almost infinite (which isnīt an option) it would be Even slower.

and back refering to ogo taiki, which had a infinite ground layer that yielded infinite global scale, as well as procedural infinite detail...(and infinite clouds, and godray globally) problem at that time, to many quality settings and hard to use, and very slow in many cases as well.

http://www.asahi-net.or.jp/~pq1a-ogs/land4.jpg

http://www.asahi-net.or.jp/~pq1a-ogs/land3.jpg

jwiede
02-25-2018, 11:38 AM
and back refering to ogo taiki, which had a infinite ground layer that yielded infinite global scale, as well as procedural infinite detail...(and infinite clouds, and godray globally) problem at that time, to many quality settings and hard to use, and very slow in many cases as well.

Well, to be fair, there's a bunch of stuff Ogo Taiki offered which simply cannot be done otherwise in LW w.r.t. skies. If you take skies out of the picture, is it really that much slower for procedural "infinite" ground?

prometheus
02-25-2018, 12:30 PM
Well, to be fair, there's a bunch of stuff Ogo Taiki offered which simply cannot be done otherwise in LW w.r.t. skies. If you take skies out of the picture, is it really that much slower for procedural "infinite" ground?

I think it was quite slow even without any volumetric clouds how much slower than the primitives, I donīt know, what I do know is that it on contrary to the primitive shapes, it could be infinite, and perhaps easier to set up texturing, but I think it was intolerable slow.

As for clouds, I wonder ..since I know the old legacy hypervoxels is much faster in 2018(not the new volumetrics), than what it was in 2015...I wonder how much faster ogo taiki volumetrics would be, if we used the legacy volumetrics, but ogo taiki was only 32 bit, lightwave 2018 only 64 bit..so that is in the grave.

a little off topic, when you load the new volumetrics and clouds, you can see that most of those volumetrics is at a 1 meter scale, not true to life scale as ogo taiki for instance, and when you scale that up..the render speed would be very slow...which means you have to sync the quality step size and it will be hard to get a good quality vs speed balance if you try the new volumetrics with more true to life scales, so samples provided as small as they are, may be a testament to it isnīt behaving well for true scales unfortunately.

the new volumetrics is quality dependent in relation to size of volumetrics and the step size, meaning quality will change when changing cloud size...and needs to be synced, while the old hypervoxels was not scale dependent, it had 5 levels of quality settings..and worked with the same render result regardless of scale of the volumetrics.
the new volumetrics is dependent on size in step size co when setting quality

jwiede
02-25-2018, 07:13 PM
a little off topic, when you load the new volumetrics and clouds, you can see that most of those volumetrics is at a 1 meter scale, not true to life scale as ogo taiki for instance, and when you scale that up..the render speed would be very slow...which means you have to sync the quality step size and it will be hard to get a good quality vs speed balance if you try the new volumetrics with more true to life scales, so samples provided as small as they are, may be a testament to it isnīt behaving well for true scales unfortunately.

the new volumetrics is quality dependent in relation to size of volumetrics and the step size, meaning quality will change when changing cloud size...and needs to be synced, while the old hypervoxels was not scale dependent, it had 5 levels of quality settings..and worked with the same render result regardless of scale of the volumetrics.
the new volumetrics is dependent on size in step size co when setting quality

That's kind of significant short-coming, as those are the kinds of situations where modeling at (or even near) scale is useful for keeping other visual aspects "realistic". Hopefully they can optimize the volumetrics further so that using them near-scale doesn't incur as much cost as it does now, or at least give users better control over how the volumetrics interpret the scale w.r.t. details.

prometheus
02-26-2018, 11:50 AM
That's kind of significant short-coming, as those are the kinds of situations where modeling at (or even near) scale is useful for keeping other visual aspects "realistic". Hopefully they can optimize the volumetrics further so that using them near-scale doesn't incur as much cost as it does now, or at least give users better control over how the volumetrics interpret the scale w.r.t. details.

Yep, a proper sunlight angle canīt be 0,52 degree for the softness shadow, if a scene is based on 1meter clouds and trying to get realistic sunshadows I believe, so you would have to mathematicly re-calculate what it
should be..I think:D otherwise we would get to large softness on the sun shadows.

jwiede
02-28-2018, 08:45 PM
Yep, a proper sunlight angle canīt be 0,52 degree for the softness shadow, if a scene is based on 1meter clouds and trying to get realistic sunshadows I believe, so you would have to mathematicly re-calculate what it
should be..I think:D otherwise we would get to large softness on the sun shadows.

The shadow softness stuff gets a bit "squirrely" (professional term :devil:) with really small fractional degree values too, like the effect has a granularity floor or something -- likely correlated to ray spacing, if I had to guess.