Found 237 posts.
Search results Show results as topic list.
Houdini Lounge » Any rumours of Houdini 19?
- lewis_T
- 237 posts
- Offline
I don't think anyone has to wonder/worry about sidefx stagnating. Unless you've been asleep in a cave since H9.
Technical Discussion » Render with exported Black levels in Houdini Solaris
- lewis_T
- 237 posts
- Offline
Not at the studios I've worked in. Night time shots, you generally would be rendering over lighted, and then grading down, that
alleviates sampling issues compared to setting up renders to be dark. The crunch, is just noise from undersampling darker areas.
As far as bringing something like that in, wouldn't you just be using a LUT? That you guys publish, that when loaded in to the
render view, would shift the levels, and allow to see it?
alleviates sampling issues compared to setting up renders to be dark. The crunch, is just noise from undersampling darker areas.
As far as bringing something like that in, wouldn't you just be using a LUT? That you guys publish, that when loaded in to the
render view, would shift the levels, and allow to see it?
Houdini Indie and Apprentice » Mantra (or any other renderer) adds spheres to my scene
- lewis_T
- 237 posts
- Offline
Waht Tomas said!
The obj level containers all have the default setting of "Render Unconnected Points."
Which is a bit stupid.
It does flag to you though that your meshes have some shitty topology.
The obj level containers all have the default setting of "Render Unconnected Points."
Which is a bit stupid.
It does flag to you though that your meshes have some shitty topology.
Technical Discussion » Render with exported Black levels in Houdini Solaris
- lewis_T
- 237 posts
- Offline
Why would you ever want to do this? The render output should not be clipped at all.
Match the black levels of your render to what your black level/white point is in Nuke.
Match the black levels of your render to what your black level/white point is in Nuke.
Houdini Lounge » A suggestion for developers...
- lewis_T
- 237 posts
- Offline
Tomas funny you mention that. I just saw an FX Artist make rainbow coloured wrangle input nubs!
What a time to be alive.
L
What a time to be alive.
L
Houdini Lounge » A suggestion for developers...
- lewis_T
- 237 posts
- Offline
They are already broken up into headings > subtypes. Color coding makes zero sense, as houdini, unlike Maya and Max, doesn't
really care 90% of the time WHAT it is operating on. Points on a mesh, or from a popsim, or a FLIP sim are just points.
Ditto for curves, volumes, etc. So you'll find most nodes can operate on what would be considered in Max and Maya, as different data types. Just take your time, and explore around. You'll remember more of them than you might think.
L
really care 90% of the time WHAT it is operating on. Points on a mesh, or from a popsim, or a FLIP sim are just points.
Ditto for curves, volumes, etc. So you'll find most nodes can operate on what would be considered in Max and Maya, as different data types. Just take your time, and explore around. You'll remember more of them than you might think.
L
Houdini Lounge » VEX: reading normals
- lewis_T
- 237 posts
- Offline
Using @N will create normals.
You only need to go, v@normal1 = @N;
You can't use @normal1 because there are a few "known" types that VEX wrangles auto sign for you.
The @N, @Cd for example. The reason it fails for you, is you are not declaring the type.
The default for undeclared is float I think, but anywho. You need to DECLARE! v@normal1 is your friend.
You only need to go, v@normal1 = @N;
You can't use @normal1 because there are a few "known" types that VEX wrangles auto sign for you.
The @N, @Cd for example. The reason it fails for you, is you are not declaring the type.
The default for undeclared is float I think, but anywho. You need to DECLARE! v@normal1 is your friend.
Edited by lewis_T - May 16, 2021 21:03:25
Houdini Lounge » Karma w/GPU
- lewis_T
- 237 posts
- Offline
No, things do not equalize when complexity increases. It's quite the opposite.
Mikkas I never suggested Mantra wasn't the most flexible. I've used it for 12yrs, at a deep level.
But it is slow. Painfully slow. A 64 core machine should indeed be rendering those scenes in decent times, but you bench
scenes against Mantra, and it falls down quickly these days.
The free aspect of a license is almost useless once you pile on render times. Quickly eaten up by Artist time/money.
Regarding complexity, really, you need to be talking multiple difficult scenarios. Geometric, motion blur, close to camera,
multiple scattering, the works.
I don't see how packed disk stuff plays into render time though. Packed and delayed helps IFD creation, but that's nothing
unique to Mantra. It all still needs to be unpacked into geometry to render.
Cheers
Lewis
Mikkas I never suggested Mantra wasn't the most flexible. I've used it for 12yrs, at a deep level.
But it is slow. Painfully slow. A 64 core machine should indeed be rendering those scenes in decent times, but you bench
scenes against Mantra, and it falls down quickly these days.
The free aspect of a license is almost useless once you pile on render times. Quickly eaten up by Artist time/money.
Regarding complexity, really, you need to be talking multiple difficult scenarios. Geometric, motion blur, close to camera,
multiple scattering, the works.
I don't see how packed disk stuff plays into render time though. Packed and delayed helps IFD creation, but that's nothing
unique to Mantra. It all still needs to be unpacked into geometry to render.
Cheers
Lewis
Edited by lewis_T - May 5, 2021 21:58:52
3rd Party » AMD Radeon ProRender Solaris plugin
- lewis_T
- 237 posts
- Offline
that's not got to do with how Houdini imports geometry though.
Those points are disconnected from the mesh, which points to the mesh being not checked/cleaned when it
was authored. This is annoying common in scanned geometry.
Those points are disconnected from the mesh, which points to the mesh being not checked/cleaned when it
was authored. This is annoying common in scanned geometry.
Houdini Lounge » clEnqueueNDRangeKernel Vellum bug ?
- lewis_T
- 237 posts
- Offline
yeah it has nothing to do with hardware, that was my point in the post. It is Driver related.
But I listed both my Quadro and 980ti, to show that it does indeed work. You should always be careful with Drivers
as updating to solve some gaming problem is going to risk breaking something in another app.
Latest is not the greatest.
But I listed both my Quadro and 980ti, to show that it does indeed work. You should always be careful with Drivers
as updating to solve some gaming problem is going to risk breaking something in another app.
Latest is not the greatest.
Houdini Lounge » Reducing Mantra rendering speeds
- lewis_T
- 237 posts
- Offline
That's a tad harsh. Solaris and Karma aren't fully there, not even close, and are a minefield for a new user.
Mantra is still usable.
Are you using any HDR's in your lights? Convert the texture over to .rat, this is mipmapped Mantra native format.
Easy to open the hdr in mplay and save as .rat, you'd be shocked at how much this impacts render time.
What are you Mantra settings? What render engine mode are you using? Is your displacement bounds, etc set correctly?
Happy to help steer you in the right direction, but I need some more info Duder.
Cheers
L
Mantra is still usable.
Are you using any HDR's in your lights? Convert the texture over to .rat, this is mipmapped Mantra native format.
Easy to open the hdr in mplay and save as .rat, you'd be shocked at how much this impacts render time.
What are you Mantra settings? What render engine mode are you using? Is your displacement bounds, etc set correctly?
Happy to help steer you in the right direction, but I need some more info Duder.
Cheers
L
Houdini Lounge » clEnqueueNDRangeKernel Vellum bug ?
- lewis_T
- 237 posts
- Offline
Not sure why you're unloading on houdini, could be you need to learn to optimize more. If it were so terrible, we'd
all still be using Max + TP + Fumefx, which is not the case.
First page of the what's new in H18.5 Vellum lists Driver versioning for use of Pressure constraints, because they
have been optimized.
what's new Vellum [www.sidefx.com]
Your GPU is more than powerful enough to run a bunch of openCL tools in houdini, this will come down to Driver versions.
I'm running a 980ti, and a Quadro at home, zero problems.
by the way, Grains are the same family, they are PBD, Vellum is just xPBD, so not much difference at all, only thing would
be that Vellum code is looked at more often that pop grains XPD potentially, so in general, Vellum grains will be quicker.
L
all still be using Max + TP + Fumefx, which is not the case.
First page of the what's new in H18.5 Vellum lists Driver versioning for use of Pressure constraints, because they
have been optimized.
what's new Vellum [www.sidefx.com]
Your GPU is more than powerful enough to run a bunch of openCL tools in houdini, this will come down to Driver versions.
I'm running a 980ti, and a Quadro at home, zero problems.
by the way, Grains are the same family, they are PBD, Vellum is just xPBD, so not much difference at all, only thing would
be that Vellum code is looked at more often that pop grains XPD potentially, so in general, Vellum grains will be quicker.
L
Edited by lewis_T - April 26, 2021 03:44:19
Houdini Lounge » Karma w/GPU
- lewis_T
- 237 posts
- Offline
Yes, exactly.
And Arnold is not free, as mentioned above. Cycles? Sure, go throw a bunch of heavy stuff at it.
The future is absolutely in 3rd party land, it was only ever a Mantra centric environment due to free render
tokens making up for slow rendering. But you go do the math, a "free" engine that is 5x-20x slower than a commercial
one at $500 per year. That "free" is very very quickly evaporated.
Brian, Karma is all USD, it is only USD. That is the point. It is not a simple replacement for Mantra, which is still
capable, but is just in Maintenance mode, nothing wrong with still using it. Karma will require a lot of work, and for
a lot of users, USD, for at least a couple more years is totally pointless. So 3rd party engines will take over, and
as USD matures into easier to use/easier to see the benefit, Karma will shine really well.
Again, I don't know what is so shocking about having to "pay" for a quality engine, Devvd internally or not. You're
already getting Houdini for not $5k, but $250 so......
And Arnold is not free, as mentioned above. Cycles? Sure, go throw a bunch of heavy stuff at it.
The future is absolutely in 3rd party land, it was only ever a Mantra centric environment due to free render
tokens making up for slow rendering. But you go do the math, a "free" engine that is 5x-20x slower than a commercial
one at $500 per year. That "free" is very very quickly evaporated.
Brian, Karma is all USD, it is only USD. That is the point. It is not a simple replacement for Mantra, which is still
capable, but is just in Maintenance mode, nothing wrong with still using it. Karma will require a lot of work, and for
a lot of users, USD, for at least a couple more years is totally pointless. So 3rd party engines will take over, and
as USD matures into easier to use/easier to see the benefit, Karma will shine really well.
Again, I don't know what is so shocking about having to "pay" for a quality engine, Devvd internally or not. You're
already getting Houdini for not $5k, but $250 so......
Houdini Lounge » Karma w/GPU
- lewis_T
- 237 posts
- Offline
@protozoan but there was indeed talk initially upon announcement of Karma existing.
From memory, it was that "we are unsure if it will be a free product." Not quoting verbatim mind you.
A Disaster if it were not free? really? Have a look around at the bundled renderer that comes with a lot
of applications over the years. Toys, absolute toys. Mantra was always a labour of love, and it's deep integration
is something to still be marveled at. If Karma were to be as performant as a 3rd party engine, then why would
it not be possibly a purchased product?
Happy for it to be either, but saying it would be a disaster if it weren't free is a bit silly.
L
From memory, it was that "we are unsure if it will be a free product." Not quoting verbatim mind you.
A Disaster if it were not free? really? Have a look around at the bundled renderer that comes with a lot
of applications over the years. Toys, absolute toys. Mantra was always a labour of love, and it's deep integration
is something to still be marveled at. If Karma were to be as performant as a 3rd party engine, then why would
it not be possibly a purchased product?
Happy for it to be either, but saying it would be a disaster if it weren't free is a bit silly.
L
Houdini Lounge » Karma w/GPU
- lewis_T
- 237 posts
- Offline
I would dial back your anticipation. Karma is not a high prio, 3rd party renderers are.
My prediction is Karma will indeed be a great tool, but that is 2yrs away from full feature set and
competitive render speeds. Remember also, that there is no solid standpoint from sesi regarding is Karma
would be free, or a paid renderer.
My prediction is Karma will indeed be a great tool, but that is 2yrs away from full feature set and
competitive render speeds. Remember also, that there is no solid standpoint from sesi regarding is Karma
would be free, or a paid renderer.
Houdini Lounge » Importing a VDB and getting a velocity from said VDB
- lewis_T
- 237 posts
- Offline
Houdini Lounge » smoke based particlesim vs. sim with vdb_vel particlesim
- lewis_T
- 237 posts
- Offline
There is none. It's about the look. Using vel from a smoke sim means you'll be getting velocities that
respect fluid dynamics, so when using them in your popsim, the points will move much more realistically in terms of vel
existing, and moving correctly in terms of physics.
You making your own vel field, that totally works also, but unless it's running through a fluid sim, it won't respect
non-divergence. Both methods are used, it only has to "look right," but having said that, it's usually much easier to use
a velocity field from a fluid sim to advect, as it's motion is correct out of the box, Vs you fighting to make your own fields
to mimic this.
I tend to use either or a combination of both in the pop sim. It really just comes down to the physically correct nature of the
field coming out of a smoke sim.
L
respect fluid dynamics, so when using them in your popsim, the points will move much more realistically in terms of vel
existing, and moving correctly in terms of physics.
You making your own vel field, that totally works also, but unless it's running through a fluid sim, it won't respect
non-divergence. Both methods are used, it only has to "look right," but having said that, it's usually much easier to use
a velocity field from a fluid sim to advect, as it's motion is correct out of the box, Vs you fighting to make your own fields
to mimic this.
I tend to use either or a combination of both in the pop sim. It really just comes down to the physically correct nature of the
field coming out of a smoke sim.
L
Houdini Indie and Apprentice » Tips for art directing high res sims?
- lewis_T
- 237 posts
- Offline
Houdini Indie and Apprentice » Tips for art directing high res sims?
- lewis_T
- 237 posts
- Offline
That's a lot of grains potentially.
I tend to use point replicate after the sim, to create the mass, as things like dirt chunks aren't like
grains of sand, you can be more coarse in your resolution, to a point. What are your substeps and iterations?
What GPU do you have?
Cheers
Lewie
I tend to use point replicate after the sim, to create the mass, as things like dirt chunks aren't like
grains of sand, you can be more coarse in your resolution, to a point. What are your substeps and iterations?
What GPU do you have?
Cheers
Lewie
Technical Discussion » Houdini to maya Alembic mesh skipping around
- lewis_T
- 237 posts
- Offline
-
- Quick Links