iRay only I'm tired of it.

Ruphuss

if you are using connect you cannot alter maps in the cloud folder

you have to create a new folder somewhere else

and the whole use smaller maps for vram is not that effective as you may think

there was a comparison already somewhere in the forums

i think mec4d did it

DaWaterRat

Ruphuss said:

if you are using connect you cannot alter maps in the cloud folder

you have to create a new folder somewhere else

Actually... I just tested that.  You can alter the Texture files in the cloud folder.  Admittedly, I made a copy of the two files I tested, rather than changing the originals, but those copies are in their respective Daz Connect cloud folders.

evilded777

kyoto kid said:

Kendall Sears said:

kyoto kid said:

hphoenix said:

kyoto kid said:

...again Fibremesh hair is very memory intensive. It would pretty much require the memory resources of a Titan-X or even Quadro M6000 to hold a complete scene. especially with multiple characters.

It is too bad Iray didn't have a similar system to Octane where it split the Geometry and Texture load.  It wouldn't be as lightning quick as pure GPU rendering but much faster than pure CPU rendering and wouldn't require a GPU with tonnes of memory at a heavyweight price..

Actually, fibermesh hair isn't that bad.  While it is a LOT of geometry, geometry itself is a lot cheaper than image maps.  Geometry is around 32 bytes per vertex, plus Face lists (3 or 4 vertex indices per face, so about 14 bytes average).  This means that STATIC geometry (no morphs/bones) works out to about 96 bytes per face or less.  So a 100,000 face mesh would only occupy about 10MB of VRAM.  Compare this to a SINGLE 4k x 4k image map, which even at 50% compression in VRAM is 32MB.

Compared to high-res textures, geometry is cheap.  So fibermesh hair is NOT that huge of a hit, memory wise.  However, the more polys in a scene, the more ray-tests and such have to be done, so it will slow down rendering.  Complex big texture maps are just table-lookups, so are pretty fast, even with decompression.  So fibermesh hair will slow your render down, but take up only a small amount of VRAM.  Strip-based textured hair will be faster to render, but takes up a lot more VRAM.  Trade-offs.  Of course, the moment you start using fancy shaders on the hair, including transparency, special specular calculations, translucency, and more, even strip-based textured hair will start to slow down the render as well.......

But in general, geometry is a lot cheaper (memory-wise) but slower (render-wise.)

 

...if you are stuck with only CPU rendering, those render times can become glacial  Also I need to make use of what I have as being on a fixed income, I cannot afford a whole new library of Fibremesh hair content to suit various different styles and lengths.  Persoanlly I like tools such as Garabaldi and LAMH as they give me the flexibility to create any style or length I need.  The drawback with Iray is they need to be imported as a .obj, and that really does pump up the polycount. So, with textures, specularity, and translucency, you get the worst of both worlds, more memory use and longer render time whreas in 3DL they render rather quickly.

LAMH FiberHair is significantly smaller than OBJ.  Using default settings as much as 40-60% smaller on average.  Some hair styles can get upwards of 80% smaller.  But FiberHair does require the full plugin and not just the free player.

Kendall

..LAMH fibre? As I reacall LAMH isalso a strand based system (Like Garabaldi) which is why it also needs to be converted to .obj to render in Iray.

Kendall is one of the programmers... I'm pretty sure he knows what the plugin can do.

Mustakettu85 said:

 

evilded777 said:

Its an impressive engine; but like any impressive engine, you need dedicated people designing unique shaders and lights. We're not getting them for Studio anymore, haven't for a long time. Maybe, when Ketu releases hers, there will be a resurgence in popularity.

 

 

Hi R :) Thank you for remembering me.

Yeah I am indeed the one who promises a suite of new RSL shaders and "scripted renderer" stuff for using the 3Delight physically plausible path tracing core straight in DS. For free. But DAZ Soon (tm) cuz real life.

Not sure about the potential popularity, though - I am building a preset library and a handful of useful scripts, but other than that, it's a strictly manual conversion of every material in the scene. C'mon, you've seen my kit - it is like a new render engine =) And it's grown since that first alpha iteration.

And using "gamma correction" is a must with my stuff.

In my experience, manual conversion doesn't take much time once you have an idea which types of materials need which values. But!! If you have a model whose surface naming makes no sense... and there are a gazillion surfaces... now, then it might take quite some time to figure out which surface is supposed to look like which material.

Surfaces that mix materials via mapping "metallicity" or whatever aren't a problem, as long as you do have maps.

 

Of course I haven't forgotten you. Just that Iray came along right around the time I started getting involved, and well... I'm lazy! I'm taking the easy way out for now.

evilded777

Ruphuss said:

if you are using connect you cannot alter maps in the cloud folder

you have to create a new folder somewhere else

and the whole use smaller maps for vram is not that effective as you may think

there was a comparison already somewhere in the forums

i think mec4d did it

Will the mis-information about Connect never cease to spill forth?

Mustakettu85

kyoto kid said:

Also what about displacement, bump and transparency maps, don't those need to have the same resolution as the diffuse?

No. 

MEC4D

All I said was about is REDUCE the resolution of all maps beside Normal, Bump , Displacement and Opacity as they need to be in higher resolution , also Bump, Specular and Opacity maps saved as grayscale will reduce the size as they are float maps and not color . If you render full figures in HD format images you not need more than 2000x2000 for color maps and that will cut the vram usage in half already , load faster in general , I wish we have an option for texture resolution the way HD environment have under Interactive mode in iray in place of the compression 

Ruphuss said:

if you are using connect you cannot alter maps in the cloud folder

you have to create a new folder somewhere else

and the whole use smaller maps for vram is not that effective as you may think

there was a comparison already somewhere in the forums

i think mec4d did it

 

kyoto kid

...it's too bad we can't do it in the Surfaces tab.

Kendall Sears

MEC4D said:

LAMH , Garibaldi or Zbrush exported OBJ are all the same geometry files, no fiber or fibre ( fiber is the actual rendered curve in each plugin or program  before exporting to obj) , Garibaldi and Zbrush exported hair have 3 side polygons option what works best in DS as it can be pretty well subdivided once for round hair tubes , more than 3 sides not recommended I don't have LAMH so I can't tell what are the setings there for export but go for 3 sides poly for best result so you can use it in scene far away not subdivided or close up subdivided and you keep the hair at the lowest poly level as you don't need more sides .

kyoto kid said:

Kendall Sears said:

kyoto kid said:

hphoenix said:

kyoto kid said:

...again Fibremesh hair is very memory intensive. It would pretty much require the memory resources of a Titan-X or even Quadro M6000 to hold a complete scene. especially with multiple characters.

It is too bad Iray didn't have a similar system to Octane where it split the Geometry and Texture load.  It wouldn't be as lightning quick as pure GPU rendering but much faster than pure CPU rendering and wouldn't require a GPU with tonnes of memory at a heavyweight price..

Actually, fibermesh hair isn't that bad.  While it is a LOT of geometry, geometry itself is a lot cheaper than image maps.  Geometry is around 32 bytes per vertex, plus Face lists (3 or 4 vertex indices per face, so about 14 bytes average).  This means that STATIC geometry (no morphs/bones) works out to about 96 bytes per face or less.  So a 100,000 face mesh would only occupy about 10MB of VRAM.  Compare this to a SINGLE 4k x 4k image map, which even at 50% compression in VRAM is 32MB.

Compared to high-res textures, geometry is cheap.  So fibermesh hair is NOT that huge of a hit, memory wise.  However, the more polys in a scene, the more ray-tests and such have to be done, so it will slow down rendering.  Complex big texture maps are just table-lookups, so are pretty fast, even with decompression.  So fibermesh hair will slow your render down, but take up only a small amount of VRAM.  Strip-based textured hair will be faster to render, but takes up a lot more VRAM.  Trade-offs.  Of course, the moment you start using fancy shaders on the hair, including transparency, special specular calculations, translucency, and more, even strip-based textured hair will start to slow down the render as well.......

But in general, geometry is a lot cheaper (memory-wise) but slower (render-wise.)

 

...if you are stuck with only CPU rendering, those render times can become glacial  Also I need to make use of what I have as being on a fixed income, I cannot afford a whole new library of Fibremesh hair content to suit various different styles and lengths.  Persoanlly I like tools such as Garabaldi and LAMH as they give me the flexibility to create any style or length I need.  The drawback with Iray is they need to be imported as a .obj, and that really does pump up the polycount. So, with textures, specularity, and translucency, you get the worst of both worlds, more memory use and longer render time whreas in 3DL they render rather quickly.

LAMH FiberHair is significantly smaller than OBJ.  Using default settings as much as 40-60% smaller on average.  Some hair styles can get upwards of 80% smaller.  But FiberHair does require the full plugin and not just the free player.

Kendall

..LAMH fibre? As I reacall LAMH isalso a strand based system (Like Garabaldi) which is why it also needs to be converted to .obj to render in Iray.

 

LAMH uses several techniques when writing out our LAMH FiberHair.  We get better definition and smaller sizes than either of the other two listed.  Our lead will increase dramatically very soon when LAMH will not need to export external files at all, OBJ format or otherwise.  And that's only one advancement, there are several more advancements that are in the pipeline to make LAMH FiberHair even more efficient.

Kendall

nonesuch00

Kendall Sears said:

MEC4D said:

LAMH , Garibaldi or Zbrush exported OBJ are all the same geometry files, no fiber or fibre ( fiber is the actual rendered curve in each plugin or program  before exporting to obj) , Garibaldi and Zbrush exported hair have 3 side polygons option what works best in DS as it can be pretty well subdivided once for round hair tubes , more than 3 sides not recommended I don't have LAMH so I can't tell what are the setings there for export but go for 3 sides poly for best result so you can use it in scene far away not subdivided or close up subdivided and you keep the hair at the lowest poly level as you don't need more sides .

kyoto kid said:

Kendall Sears said:

kyoto kid said:

hphoenix said:

kyoto kid said:

...again Fibremesh hair is very memory intensive. It would pretty much require the memory resources of a Titan-X or even Quadro M6000 to hold a complete scene. especially with multiple characters.

It is too bad Iray didn't have a similar system to Octane where it split the Geometry and Texture load.  It wouldn't be as lightning quick as pure GPU rendering but much faster than pure CPU rendering and wouldn't require a GPU with tonnes of memory at a heavyweight price..

Actually, fibermesh hair isn't that bad.  While it is a LOT of geometry, geometry itself is a lot cheaper than image maps.  Geometry is around 32 bytes per vertex, plus Face lists (3 or 4 vertex indices per face, so about 14 bytes average).  This means that STATIC geometry (no morphs/bones) works out to about 96 bytes per face or less.  So a 100,000 face mesh would only occupy about 10MB of VRAM.  Compare this to a SINGLE 4k x 4k image map, which even at 50% compression in VRAM is 32MB.

Compared to high-res textures, geometry is cheap.  So fibermesh hair is NOT that huge of a hit, memory wise.  However, the more polys in a scene, the more ray-tests and such have to be done, so it will slow down rendering.  Complex big texture maps are just table-lookups, so are pretty fast, even with decompression.  So fibermesh hair will slow your render down, but take up only a small amount of VRAM.  Strip-based textured hair will be faster to render, but takes up a lot more VRAM.  Trade-offs.  Of course, the moment you start using fancy shaders on the hair, including transparency, special specular calculations, translucency, and more, even strip-based textured hair will start to slow down the render as well.......

But in general, geometry is a lot cheaper (memory-wise) but slower (render-wise.)

 

...if you are stuck with only CPU rendering, those render times can become glacial  Also I need to make use of what I have as being on a fixed income, I cannot afford a whole new library of Fibremesh hair content to suit various different styles and lengths.  Persoanlly I like tools such as Garabaldi and LAMH as they give me the flexibility to create any style or length I need.  The drawback with Iray is they need to be imported as a .obj, and that really does pump up the polycount. So, with textures, specularity, and translucency, you get the worst of both worlds, more memory use and longer render time whreas in 3DL they render rather quickly.

LAMH FiberHair is significantly smaller than OBJ.  Using default settings as much as 40-60% smaller on average.  Some hair styles can get upwards of 80% smaller.  But FiberHair does require the full plugin and not just the free player.

Kendall

..LAMH fibre? As I reacall LAMH isalso a strand based system (Like Garabaldi) which is why it also needs to be converted to .obj to render in Iray.

 

LAMH uses several techniques when writing out our LAMH FiberHair.  We get better definition and smaller sizes than either of the other two listed.  Our lead will increase dramatically very soon when LAMH will not need to export external files at all, OBJ format or otherwise.  And that's only one advancement, there are several more advancements that are in the pipeline to make LAMH FiberHair even more efficient.

Kendall

Oh, boy. That's good to hear.

MEC4D

I wish , there may be a way for the DS programers to do that as they did with the HDR enviorment map under Internactive mode , just slider with resolution and store the files in  temporery folder or at last more options under texture compresion so you can decide how low you want to go and not just medium and high as how much is high here , not enough to save a lot of vram 

maybe one day we can use RAM for that, iray is still young who knows what the future brings 

kyoto kid said:

...it's too bad we can't do it in the Surfaces tab.

 

MEC4D

That are good news Kendall, I guess I will have to switch soon to LAMH ;)  the reason I did not yet as I can do the same in other programs as I don't render anymore with 3DL, so thanks for the good news !

Kendall Sears said:

MEC4D said:

LAMH , Garibaldi or Zbrush exported OBJ are all the same geometry files, no fiber or fibre ( fiber is the actual rendered curve in each plugin or program  before exporting to obj) , Garibaldi and Zbrush exported hair have 3 side polygons option what works best in DS as it can be pretty well subdivided once for round hair tubes , more than 3 sides not recommended I don't have LAMH so I can't tell what are the setings there for export but go for 3 sides poly for best result so you can use it in scene far away not subdivided or close up subdivided and you keep the hair at the lowest poly level as you don't need more sides .

kyoto kid said:

Kendall Sears said:

kyoto kid said:

hphoenix said:

kyoto kid said:

...again Fibremesh hair is very memory intensive. It would pretty much require the memory resources of a Titan-X or even Quadro M6000 to hold a complete scene. especially with multiple characters.

It is too bad Iray didn't have a similar system to Octane where it split the Geometry and Texture load.  It wouldn't be as lightning quick as pure GPU rendering but much faster than pure CPU rendering and wouldn't require a GPU with tonnes of memory at a heavyweight price..

Actually, fibermesh hair isn't that bad.  While it is a LOT of geometry, geometry itself is a lot cheaper than image maps.  Geometry is around 32 bytes per vertex, plus Face lists (3 or 4 vertex indices per face, so about 14 bytes average).  This means that STATIC geometry (no morphs/bones) works out to about 96 bytes per face or less.  So a 100,000 face mesh would only occupy about 10MB of VRAM.  Compare this to a SINGLE 4k x 4k image map, which even at 50% compression in VRAM is 32MB.

Compared to high-res textures, geometry is cheap.  So fibermesh hair is NOT that huge of a hit, memory wise.  However, the more polys in a scene, the more ray-tests and such have to be done, so it will slow down rendering.  Complex big texture maps are just table-lookups, so are pretty fast, even with decompression.  So fibermesh hair will slow your render down, but take up only a small amount of VRAM.  Strip-based textured hair will be faster to render, but takes up a lot more VRAM.  Trade-offs.  Of course, the moment you start using fancy shaders on the hair, including transparency, special specular calculations, translucency, and more, even strip-based textured hair will start to slow down the render as well.......

But in general, geometry is a lot cheaper (memory-wise) but slower (render-wise.)

 

...if you are stuck with only CPU rendering, those render times can become glacial  Also I need to make use of what I have as being on a fixed income, I cannot afford a whole new library of Fibremesh hair content to suit various different styles and lengths.  Persoanlly I like tools such as Garabaldi and LAMH as they give me the flexibility to create any style or length I need.  The drawback with Iray is they need to be imported as a .obj, and that really does pump up the polycount. So, with textures, specularity, and translucency, you get the worst of both worlds, more memory use and longer render time whreas in 3DL they render rather quickly.

LAMH FiberHair is significantly smaller than OBJ.  Using default settings as much as 40-60% smaller on average.  Some hair styles can get upwards of 80% smaller.  But FiberHair does require the full plugin and not just the free player.

Kendall

..LAMH fibre? As I reacall LAMH isalso a strand based system (Like Garabaldi) which is why it also needs to be converted to .obj to render in Iray.

 

LAMH uses several techniques when writing out our LAMH FiberHair.  We get better definition and smaller sizes than either of the other two listed.  Our lead will increase dramatically very soon when LAMH will not need to export external files at all, OBJ format or otherwise.  And that's only one advancement, there are several more advancements that are in the pipeline to make LAMH FiberHair even more efficient.

Kendall

 

Kendall Sears

MEC4D said:

That are good news Kendall, I guess I will have to switch soon to LAMH ;)  the reason I did not yet as I can do the same in other programs as I don't render anymore with 3DL, so thanks for the good news !

Kendall Sears said:

MEC4D said:

LAMH , Garibaldi or Zbrush exported OBJ are all the same geometry files, no fiber or fibre ( fiber is the actual rendered curve in each plugin or program  before exporting to obj) , Garibaldi and Zbrush exported hair have 3 side polygons option what works best in DS as it can be pretty well subdivided once for round hair tubes , more than 3 sides not recommended I don't have LAMH so I can't tell what are the setings there for export but go for 3 sides poly for best result so you can use it in scene far away not subdivided or close up subdivided and you keep the hair at the lowest poly level as you don't need more sides .

kyoto kid said:

Kendall Sears said:

kyoto kid said:

hphoenix said:

kyoto kid said:

...again Fibremesh hair is very memory intensive. It would pretty much require the memory resources of a Titan-X or even Quadro M6000 to hold a complete scene. especially with multiple characters.

It is too bad Iray didn't have a similar system to Octane where it split the Geometry and Texture load.  It wouldn't be as lightning quick as pure GPU rendering but much faster than pure CPU rendering and wouldn't require a GPU with tonnes of memory at a heavyweight price..

Actually, fibermesh hair isn't that bad.  While it is a LOT of geometry, geometry itself is a lot cheaper than image maps.  Geometry is around 32 bytes per vertex, plus Face lists (3 or 4 vertex indices per face, so about 14 bytes average).  This means that STATIC geometry (no morphs/bones) works out to about 96 bytes per face or less.  So a 100,000 face mesh would only occupy about 10MB of VRAM.  Compare this to a SINGLE 4k x 4k image map, which even at 50% compression in VRAM is 32MB.

Compared to high-res textures, geometry is cheap.  So fibermesh hair is NOT that huge of a hit, memory wise.  However, the more polys in a scene, the more ray-tests and such have to be done, so it will slow down rendering.  Complex big texture maps are just table-lookups, so are pretty fast, even with decompression.  So fibermesh hair will slow your render down, but take up only a small amount of VRAM.  Strip-based textured hair will be faster to render, but takes up a lot more VRAM.  Trade-offs.  Of course, the moment you start using fancy shaders on the hair, including transparency, special specular calculations, translucency, and more, even strip-based textured hair will start to slow down the render as well.......

But in general, geometry is a lot cheaper (memory-wise) but slower (render-wise.)

 

...if you are stuck with only CPU rendering, those render times can become glacial  Also I need to make use of what I have as being on a fixed income, I cannot afford a whole new library of Fibremesh hair content to suit various different styles and lengths.  Persoanlly I like tools such as Garabaldi and LAMH as they give me the flexibility to create any style or length I need.  The drawback with Iray is they need to be imported as a .obj, and that really does pump up the polycount. So, with textures, specularity, and translucency, you get the worst of both worlds, more memory use and longer render time whreas in 3DL they render rather quickly.

LAMH FiberHair is significantly smaller than OBJ.  Using default settings as much as 40-60% smaller on average.  Some hair styles can get upwards of 80% smaller.  But FiberHair does require the full plugin and not just the free player.

Kendall

..LAMH fibre? As I reacall LAMH isalso a strand based system (Like Garabaldi) which is why it also needs to be converted to .obj to render in Iray.

 

LAMH uses several techniques when writing out our LAMH FiberHair.  We get better definition and smaller sizes than either of the other two listed.  Our lead will increase dramatically very soon when LAMH will not need to export external files at all, OBJ format or otherwise.  And that's only one advancement, there are several more advancements that are in the pipeline to make LAMH FiberHair even more efficient.

Kendall

 

LAMH has supported OBJ since the beginning in Dec of 2012.  LAMH FiberHair feature was released not long after that.  So one could say that LAMH supported Iray before Iray was in DS.  LAMH FiberHair has always been able to be directly attached to the model in the DS viewport without exporting to external files, unlike our competition.

Kendall

MEC4D

I know that , I just wanted to have better control over the exported geometey  as I can do in Zbrush , from 1 flat poly to how many faces and segments I want and easy redone without living DS from begining to the end of the process . So looking forward to see new features and the progress 

Kendall Sears said:

MEC4D said:

That are good news Kendall, I guess I will have to switch soon to LAMH ;)  the reason I did not yet as I can do the same in other programs as I don't render anymore with 3DL, so thanks for the good news !

Kendall Sears said:

MEC4D said:

LAMH , Garibaldi or Zbrush exported OBJ are all the same geometry files, no fiber or fibre ( fiber is the actual rendered curve in each plugin or program  before exporting to obj) , Garibaldi and Zbrush exported hair have 3 side polygons option what works best in DS as it can be pretty well subdivided once for round hair tubes , more than 3 sides not recommended I don't have LAMH so I can't tell what are the setings there for export but go for 3 sides poly for best result so you can use it in scene far away not subdivided or close up subdivided and you keep the hair at the lowest poly level as you don't need more sides .

kyoto kid said:

Kendall Sears said:

kyoto kid said:

hphoenix said:

kyoto kid said:

...again Fibremesh hair is very memory intensive. It would pretty much require the memory resources of a Titan-X or even Quadro M6000 to hold a complete scene. especially with multiple characters.

It is too bad Iray didn't have a similar system to Octane where it split the Geometry and Texture load.  It wouldn't be as lightning quick as pure GPU rendering but much faster than pure CPU rendering and wouldn't require a GPU with tonnes of memory at a heavyweight price..

Actually, fibermesh hair isn't that bad.  While it is a LOT of geometry, geometry itself is a lot cheaper than image maps.  Geometry is around 32 bytes per vertex, plus Face lists (3 or 4 vertex indices per face, so about 14 bytes average).  This means that STATIC geometry (no morphs/bones) works out to about 96 bytes per face or less.  So a 100,000 face mesh would only occupy about 10MB of VRAM.  Compare this to a SINGLE 4k x 4k image map, which even at 50% compression in VRAM is 32MB.

Compared to high-res textures, geometry is cheap.  So fibermesh hair is NOT that huge of a hit, memory wise.  However, the more polys in a scene, the more ray-tests and such have to be done, so it will slow down rendering.  Complex big texture maps are just table-lookups, so are pretty fast, even with decompression.  So fibermesh hair will slow your render down, but take up only a small amount of VRAM.  Strip-based textured hair will be faster to render, but takes up a lot more VRAM.  Trade-offs.  Of course, the moment you start using fancy shaders on the hair, including transparency, special specular calculations, translucency, and more, even strip-based textured hair will start to slow down the render as well.......

But in general, geometry is a lot cheaper (memory-wise) but slower (render-wise.)

 

...if you are stuck with only CPU rendering, those render times can become glacial  Also I need to make use of what I have as being on a fixed income, I cannot afford a whole new library of Fibremesh hair content to suit various different styles and lengths.  Persoanlly I like tools such as Garabaldi and LAMH as they give me the flexibility to create any style or length I need.  The drawback with Iray is they need to be imported as a .obj, and that really does pump up the polycount. So, with textures, specularity, and translucency, you get the worst of both worlds, more memory use and longer render time whreas in 3DL they render rather quickly.

LAMH FiberHair is significantly smaller than OBJ.  Using default settings as much as 40-60% smaller on average.  Some hair styles can get upwards of 80% smaller.  But FiberHair does require the full plugin and not just the free player.

Kendall

..LAMH fibre? As I reacall LAMH isalso a strand based system (Like Garabaldi) which is why it also needs to be converted to .obj to render in Iray.

 

LAMH uses several techniques when writing out our LAMH FiberHair.  We get better definition and smaller sizes than either of the other two listed.  Our lead will increase dramatically very soon when LAMH will not need to export external files at all, OBJ format or otherwise.  And that's only one advancement, there are several more advancements that are in the pipeline to make LAMH FiberHair even more efficient.

Kendall

 

LAMH has supported OBJ since the beginning in Dec of 2012.  LAMH FiberHair feature was released not long after that.  So one could say that LAMH supported Iray before Iray was in DS.  LAMH FiberHair has always been able to be directly attached to the model in the DS viewport without exporting to external files, unlike our competition.

Kendall

 

Kendall Sears

Kendall Sears said:

MEC4D said:

That are good news Kendall, I guess I will have to switch soon to LAMH ;)  the reason I did not yet as I can do the same in other programs as I don't render anymore with 3DL, so thanks for the good news !

Kendall Sears said:

MEC4D said:

LAMH , Garibaldi or Zbrush exported OBJ are all the same geometry files, no fiber or fibre ( fiber is the actual rendered curve in each plugin or program  before exporting to obj) , Garibaldi and Zbrush exported hair have 3 side polygons option what works best in DS as it can be pretty well subdivided once for round hair tubes , more than 3 sides not recommended I don't have LAMH so I can't tell what are the setings there for export but go for 3 sides poly for best result so you can use it in scene far away not subdivided or close up subdivided and you keep the hair at the lowest poly level as you don't need more sides .

kyoto kid said:

Kendall Sears said:

kyoto kid said:

hphoenix said:

kyoto kid said:

...again Fibremesh hair is very memory intensive. It would pretty much require the memory resources of a Titan-X or even Quadro M6000 to hold a complete scene. especially with multiple characters.

It is too bad Iray didn't have a similar system to Octane where it split the Geometry and Texture load.  It wouldn't be as lightning quick as pure GPU rendering but much faster than pure CPU rendering and wouldn't require a GPU with tonnes of memory at a heavyweight price..

Actually, fibermesh hair isn't that bad.  While it is a LOT of geometry, geometry itself is a lot cheaper than image maps.  Geometry is around 32 bytes per vertex, plus Face lists (3 or 4 vertex indices per face, so about 14 bytes average).  This means that STATIC geometry (no morphs/bones) works out to about 96 bytes per face or less.  So a 100,000 face mesh would only occupy about 10MB of VRAM.  Compare this to a SINGLE 4k x 4k image map, which even at 50% compression in VRAM is 32MB.

Compared to high-res textures, geometry is cheap.  So fibermesh hair is NOT that huge of a hit, memory wise.  However, the more polys in a scene, the more ray-tests and such have to be done, so it will slow down rendering.  Complex big texture maps are just table-lookups, so are pretty fast, even with decompression.  So fibermesh hair will slow your render down, but take up only a small amount of VRAM.  Strip-based textured hair will be faster to render, but takes up a lot more VRAM.  Trade-offs.  Of course, the moment you start using fancy shaders on the hair, including transparency, special specular calculations, translucency, and more, even strip-based textured hair will start to slow down the render as well.......

But in general, geometry is a lot cheaper (memory-wise) but slower (render-wise.)

 

...if you are stuck with only CPU rendering, those render times can become glacial  Also I need to make use of what I have as being on a fixed income, I cannot afford a whole new library of Fibremesh hair content to suit various different styles and lengths.  Persoanlly I like tools such as Garabaldi and LAMH as they give me the flexibility to create any style or length I need.  The drawback with Iray is they need to be imported as a .obj, and that really does pump up the polycount. So, with textures, specularity, and translucency, you get the worst of both worlds, more memory use and longer render time whreas in 3DL they render rather quickly.

LAMH FiberHair is significantly smaller than OBJ.  Using default settings as much as 40-60% smaller on average.  Some hair styles can get upwards of 80% smaller.  But FiberHair does require the full plugin and not just the free player.

Kendall

..LAMH fibre? As I reacall LAMH isalso a strand based system (Like Garabaldi) which is why it also needs to be converted to .obj to render in Iray.

 

LAMH uses several techniques when writing out our LAMH FiberHair.  We get better definition and smaller sizes than either of the other two listed.  Our lead will increase dramatically very soon when LAMH will not need to export external files at all, OBJ format or otherwise.  And that's only one advancement, there are several more advancements that are in the pipeline to make LAMH FiberHair even more efficient.

Kendall

 

LAMH has supported OBJ since the beginning in 2012.  LAMH FiberHair feature was released not long after that.  So one could say that LAMH supported Iray before Iray was in DS.  LAMH FiberHair has always been able to be directly attached to the model in the DS viewport without exporting to external files, unlike our competition.

Kendall

 

MEC4D said:

I know that , I just wanted to have better control over the exported geometey  as I can do in Zbrush , from 1 flat poly to how many faces and segments I want and easy redone without living DS from begining to the end of the process . So looking forward to see new features and the progress 

Kendall Sears said:

MEC4D said:

That are good news Kendall, I guess I will have to switch soon to LAMH ;)  the reason I did not yet as I can do the same in other programs as I don't render anymore with 3DL, so thanks for the good news !

Kendall Sears said:

MEC4D said:

LAMH , Garibaldi or Zbrush exported OBJ are all the same geometry files, no fiber or fibre ( fiber is the actual rendered curve in each plugin or program  before exporting to obj) , Garibaldi and Zbrush exported hair have 3 side polygons option what works best in DS as it can be pretty well subdivided once for round hair tubes , more than 3 sides not recommended I don't have LAMH so I can't tell what are the setings there for export but go for 3 sides poly for best result so you can use it in scene far away not subdivided or close up subdivided and you keep the hair at the lowest poly level as you don't need more sides .

kyoto kid said:

Kendall Sears said:

kyoto kid said:

hphoenix said:

kyoto kid said:

...again Fibremesh hair is very memory intensive. It would pretty much require the memory resources of a Titan-X or even Quadro M6000 to hold a complete scene. especially with multiple characters.

It is too bad Iray didn't have a similar system to Octane where it split the Geometry and Texture load.  It wouldn't be as lightning quick as pure GPU rendering but much faster than pure CPU rendering and wouldn't require a GPU with tonnes of memory at a heavyweight price..

Actually, fibermesh hair isn't that bad.  While it is a LOT of geometry, geometry itself is a lot cheaper than image maps.  Geometry is around 32 bytes per vertex, plus Face lists (3 or 4 vertex indices per face, so about 14 bytes average).  This means that STATIC geometry (no morphs/bones) works out to about 96 bytes per face or less.  So a 100,000 face mesh would only occupy about 10MB of VRAM.  Compare this to a SINGLE 4k x 4k image map, which even at 50% compression in VRAM is 32MB.

Compared to high-res textures, geometry is cheap.  So fibermesh hair is NOT that huge of a hit, memory wise.  However, the more polys in a scene, the more ray-tests and such have to be done, so it will slow down rendering.  Complex big texture maps are just table-lookups, so are pretty fast, even with decompression.  So fibermesh hair will slow your render down, but take up only a small amount of VRAM.  Strip-based textured hair will be faster to render, but takes up a lot more VRAM.  Trade-offs.  Of course, the moment you start using fancy shaders on the hair, including transparency, special specular calculations, translucency, and more, even strip-based textured hair will start to slow down the render as well.......

But in general, geometry is a lot cheaper (memory-wise) but slower (render-wise.)

 

...if you are stuck with only CPU rendering, those render times can become glacial  Also I need to make use of what I have as being on a fixed income, I cannot afford a whole new library of Fibremesh hair content to suit various different styles and lengths.  Persoanlly I like tools such as Garabaldi and LAMH as they give me the flexibility to create any style or length I need.  The drawback with Iray is they need to be imported as a .obj, and that really does pump up the polycount. So, with textures, specularity, and translucency, you get the worst of both worlds, more memory use and longer render time whreas in 3DL they render rather quickly.

LAMH FiberHair is significantly smaller than OBJ.  Using default settings as much as 40-60% smaller on average.  Some hair styles can get upwards of 80% smaller.  But FiberHair does require the full plugin and not just the free player.

Kendall

..LAMH fibre? As I reacall LAMH isalso a strand based system (Like Garabaldi) which is why it also needs to be converted to .obj to render in Iray.

 

LAMH uses several techniques when writing out our LAMH FiberHair.  We get better definition and smaller sizes than either of the other two listed.  Our lead will increase dramatically very soon when LAMH will not need to export external files at all, OBJ format or otherwise.  And that's only one advancement, there are several more advancements that are in the pipeline to make LAMH FiberHair even more efficient.

Kendall

 

LAMH has supported OBJ since the beginning in Dec of 2012.  LAMH FiberHair feature was released not long after that.  So one could say that LAMH supported Iray before Iray was in DS.  LAMH FiberHair has always been able to be directly attached to the model in the DS viewport without exporting to external files, unlike our competition.

Kendall

 

I see.  A feature like you describe was once in a test version.  It was deemed "not useful" because flat hairs were too easy to have disappear upon camera movement.  Testing showed that no one ever played with it.  Also, the methods we use are so good that little or nothing is gained by those kinds of tricks.

Kendall

MEC4D

They are but not for scalp hair however great for other things , with a little twist by the root all will show up on all angles , you can use it for vegetation or for trees and there is a lot of other handy usages with one side poly fibers like leaves etc.. but for that all you need the proper control of the fibers geometry .

Kendall Sears said:

Kendall Sears said:

MEC4D said:

That are good news Kendall, I guess I will have to switch soon to LAMH ;)  the reason I did not yet as I can do the same in other programs as I don't render anymore with 3DL, so thanks for the good news !

Kendall Sears said:

MEC4D said:

LAMH , Garibaldi or Zbrush exported OBJ are all the same geometry files, no fiber or fibre ( fiber is the actual rendered curve in each plugin or program  before exporting to obj) , Garibaldi and Zbrush exported hair have 3 side polygons option what works best in DS as it can be pretty well subdivided once for round hair tubes , more than 3 sides not recommended I don't have LAMH so I can't tell what are the setings there for export but go for 3 sides poly for best result so you can use it in scene far away not subdivided or close up subdivided and you keep the hair at the lowest poly level as you don't need more sides .

kyoto kid said:

Kendall Sears said:

kyoto kid said:

hphoenix said:

kyoto kid said:

...again Fibremesh hair is very memory intensive. It would pretty much require the memory resources of a Titan-X or even Quadro M6000 to hold a complete scene. especially with multiple characters.

It is too bad Iray didn't have a similar system to Octane where it split the Geometry and Texture load.  It wouldn't be as lightning quick as pure GPU rendering but much faster than pure CPU rendering and wouldn't require a GPU with tonnes of memory at a heavyweight price..

Actually, fibermesh hair isn't that bad.  While it is a LOT of geometry, geometry itself is a lot cheaper than image maps.  Geometry is around 32 bytes per vertex, plus Face lists (3 or 4 vertex indices per face, so about 14 bytes average).  This means that STATIC geometry (no morphs/bones) works out to about 96 bytes per face or less.  So a 100,000 face mesh would only occupy about 10MB of VRAM.  Compare this to a SINGLE 4k x 4k image map, which even at 50% compression in VRAM is 32MB.

Compared to high-res textures, geometry is cheap.  So fibermesh hair is NOT that huge of a hit, memory wise.  However, the more polys in a scene, the more ray-tests and such have to be done, so it will slow down rendering.  Complex big texture maps are just table-lookups, so are pretty fast, even with decompression.  So fibermesh hair will slow your render down, but take up only a small amount of VRAM.  Strip-based textured hair will be faster to render, but takes up a lot more VRAM.  Trade-offs.  Of course, the moment you start using fancy shaders on the hair, including transparency, special specular calculations, translucency, and more, even strip-based textured hair will start to slow down the render as well.......

But in general, geometry is a lot cheaper (memory-wise) but slower (render-wise.)

 

...if you are stuck with only CPU rendering, those render times can become glacial  Also I need to make use of what I have as being on a fixed income, I cannot afford a whole new library of Fibremesh hair content to suit various different styles and lengths.  Persoanlly I like tools such as Garabaldi and LAMH as they give me the flexibility to create any style or length I need.  The drawback with Iray is they need to be imported as a .obj, and that really does pump up the polycount. So, with textures, specularity, and translucency, you get the worst of both worlds, more memory use and longer render time whreas in 3DL they render rather quickly.

LAMH FiberHair is significantly smaller than OBJ.  Using default settings as much as 40-60% smaller on average.  Some hair styles can get upwards of 80% smaller.  But FiberHair does require the full plugin and not just the free player.

Kendall

..LAMH fibre? As I reacall LAMH isalso a strand based system (Like Garabaldi) which is why it also needs to be converted to .obj to render in Iray.

 

LAMH uses several techniques when writing out our LAMH FiberHair.  We get better definition and smaller sizes than either of the other two listed.  Our lead will increase dramatically very soon when LAMH will not need to export external files at all, OBJ format or otherwise.  And that's only one advancement, there are several more advancements that are in the pipeline to make LAMH FiberHair even more efficient.

Kendall

 

LAMH has supported OBJ since the beginning in 2012.  LAMH FiberHair feature was released not long after that.  So one could say that LAMH supported Iray before Iray was in DS.  LAMH FiberHair has always been able to be directly attached to the model in the DS viewport without exporting to external files, unlike our competition.

Kendall

 

MEC4D said:

I know that , I just wanted to have better control over the exported geometey  as I can do in Zbrush , from 1 flat poly to how many faces and segments I want and easy redone without living DS from begining to the end of the process . So looking forward to see new features and the progress 

Kendall Sears said:

MEC4D said:

That are good news Kendall, I guess I will have to switch soon to LAMH ;)  the reason I did not yet as I can do the same in other programs as I don't render anymore with 3DL, so thanks for the good news !

Kendall Sears said:

MEC4D said:

LAMH , Garibaldi or Zbrush exported OBJ are all the same geometry files, no fiber or fibre ( fiber is the actual rendered curve in each plugin or program  before exporting to obj) , Garibaldi and Zbrush exported hair have 3 side polygons option what works best in DS as it can be pretty well subdivided once for round hair tubes , more than 3 sides not recommended I don't have LAMH so I can't tell what are the setings there for export but go for 3 sides poly for best result so you can use it in scene far away not subdivided or close up subdivided and you keep the hair at the lowest poly level as you don't need more sides .

kyoto kid said:

Kendall Sears said:

kyoto kid said:

hphoenix said:

kyoto kid said:

...again Fibremesh hair is very memory intensive. It would pretty much require the memory resources of a Titan-X or even Quadro M6000 to hold a complete scene. especially with multiple characters.

It is too bad Iray didn't have a similar system to Octane where it split the Geometry and Texture load.  It wouldn't be as lightning quick as pure GPU rendering but much faster than pure CPU rendering and wouldn't require a GPU with tonnes of memory at a heavyweight price..

Actually, fibermesh hair isn't that bad.  While it is a LOT of geometry, geometry itself is a lot cheaper than image maps.  Geometry is around 32 bytes per vertex, plus Face lists (3 or 4 vertex indices per face, so about 14 bytes average).  This means that STATIC geometry (no morphs/bones) works out to about 96 bytes per face or less.  So a 100,000 face mesh would only occupy about 10MB of VRAM.  Compare this to a SINGLE 4k x 4k image map, which even at 50% compression in VRAM is 32MB.

Compared to high-res textures, geometry is cheap.  So fibermesh hair is NOT that huge of a hit, memory wise.  However, the more polys in a scene, the more ray-tests and such have to be done, so it will slow down rendering.  Complex big texture maps are just table-lookups, so are pretty fast, even with decompression.  So fibermesh hair will slow your render down, but take up only a small amount of VRAM.  Strip-based textured hair will be faster to render, but takes up a lot more VRAM.  Trade-offs.  Of course, the moment you start using fancy shaders on the hair, including transparency, special specular calculations, translucency, and more, even strip-based textured hair will start to slow down the render as well.......

But in general, geometry is a lot cheaper (memory-wise) but slower (render-wise.)

 

...if you are stuck with only CPU rendering, those render times can become glacial  Also I need to make use of what I have as being on a fixed income, I cannot afford a whole new library of Fibremesh hair content to suit various different styles and lengths.  Persoanlly I like tools such as Garabaldi and LAMH as they give me the flexibility to create any style or length I need.  The drawback with Iray is they need to be imported as a .obj, and that really does pump up the polycount. So, with textures, specularity, and translucency, you get the worst of both worlds, more memory use and longer render time whreas in 3DL they render rather quickly.

LAMH FiberHair is significantly smaller than OBJ.  Using default settings as much as 40-60% smaller on average.  Some hair styles can get upwards of 80% smaller.  But FiberHair does require the full plugin and not just the free player.

Kendall

..LAMH fibre? As I reacall LAMH isalso a strand based system (Like Garabaldi) which is why it also needs to be converted to .obj to render in Iray.

 

LAMH uses several techniques when writing out our LAMH FiberHair.  We get better definition and smaller sizes than either of the other two listed.  Our lead will increase dramatically very soon when LAMH will not need to export external files at all, OBJ format or otherwise.  And that's only one advancement, there are several more advancements that are in the pipeline to make LAMH FiberHair even more efficient.

Kendall

 

LAMH has supported OBJ since the beginning in Dec of 2012.  LAMH FiberHair feature was released not long after that.  So one could say that LAMH supported Iray before Iray was in DS.  LAMH FiberHair has always been able to be directly attached to the model in the DS viewport without exporting to external files, unlike our competition.

Kendall

 

I see.  A feature like you describe was once in a test version.  It was deemed "not useful" because flat hairs were too easy to have disappear upon camera movement.  Testing showed that no one ever played with it.  Also, the methods we use are so good that little or nothing is gained by those kinds of tricks.

Kendall

 

Kendall Sears

MEC4D said:

They are but not for scalp hair however great for other things , with a little twist by the root all will show up on all angles , you can use it for vegetation or for trees and there is a lot of other handy usages with one side poly fibers like leaves etc.. but for that all you need the proper control of the fibers geometry .

Kendall Sears said:

Kendall Sears said:

MEC4D said:

That are good news Kendall, I guess I will have to switch soon to LAMH ;)  the reason I did not yet as I can do the same in other programs as I don't render anymore with 3DL, so thanks for the good news !

Kendall Sears said:

MEC4D said:

LAMH , Garibaldi or Zbrush exported OBJ are all the same geometry files, no fiber or fibre ( fiber is the actual rendered curve in each plugin or program  before exporting to obj) , Garibaldi and Zbrush exported hair have 3 side polygons option what works best in DS as it can be pretty well subdivided once for round hair tubes , more than 3 sides not recommended I don't have LAMH so I can't tell what are the setings there for export but go for 3 sides poly for best result so you can use it in scene far away not subdivided or close up subdivided and you keep the hair at the lowest poly level as you don't need more sides .

kyoto kid said:

Kendall Sears said:

kyoto kid said:

hphoenix said:

kyoto kid said:

...again Fibremesh hair is very memory intensive. It would pretty much require the memory resources of a Titan-X or even Quadro M6000 to hold a complete scene. especially with multiple characters.

It is too bad Iray didn't have a similar system to Octane where it split the Geometry and Texture load.  It wouldn't be as lightning quick as pure GPU rendering but much faster than pure CPU rendering and wouldn't require a GPU with tonnes of memory at a heavyweight price..

Actually, fibermesh hair isn't that bad.  While it is a LOT of geometry, geometry itself is a lot cheaper than image maps.  Geometry is around 32 bytes per vertex, plus Face lists (3 or 4 vertex indices per face, so about 14 bytes average).  This means that STATIC geometry (no morphs/bones) works out to about 96 bytes per face or less.  So a 100,000 face mesh would only occupy about 10MB of VRAM.  Compare this to a SINGLE 4k x 4k image map, which even at 50% compression in VRAM is 32MB.

Compared to high-res textures, geometry is cheap.  So fibermesh hair is NOT that huge of a hit, memory wise.  However, the more polys in a scene, the more ray-tests and such have to be done, so it will slow down rendering.  Complex big texture maps are just table-lookups, so are pretty fast, even with decompression.  So fibermesh hair will slow your render down, but take up only a small amount of VRAM.  Strip-based textured hair will be faster to render, but takes up a lot more VRAM.  Trade-offs.  Of course, the moment you start using fancy shaders on the hair, including transparency, special specular calculations, translucency, and more, even strip-based textured hair will start to slow down the render as well.......

But in general, geometry is a lot cheaper (memory-wise) but slower (render-wise.)

 

...if you are stuck with only CPU rendering, those render times can become glacial  Also I need to make use of what I have as being on a fixed income, I cannot afford a whole new library of Fibremesh hair content to suit various different styles and lengths.  Persoanlly I like tools such as Garabaldi and LAMH as they give me the flexibility to create any style or length I need.  The drawback with Iray is they need to be imported as a .obj, and that really does pump up the polycount. So, with textures, specularity, and translucency, you get the worst of both worlds, more memory use and longer render time whreas in 3DL they render rather quickly.

LAMH FiberHair is significantly smaller than OBJ.  Using default settings as much as 40-60% smaller on average.  Some hair styles can get upwards of 80% smaller.  But FiberHair does require the full plugin and not just the free player.

Kendall

..LAMH fibre? As I reacall LAMH isalso a strand based system (Like Garabaldi) which is why it also needs to be converted to .obj to render in Iray.

 

LAMH uses several techniques when writing out our LAMH FiberHair.  We get better definition and smaller sizes than either of the other two listed.  Our lead will increase dramatically very soon when LAMH will not need to export external files at all, OBJ format or otherwise.  And that's only one advancement, there are several more advancements that are in the pipeline to make LAMH FiberHair even more efficient.

Kendall

 

LAMH has supported OBJ since the beginning in 2012.  LAMH FiberHair feature was released not long after that.  So one could say that LAMH supported Iray before Iray was in DS.  LAMH FiberHair has always been able to be directly attached to the model in the DS viewport without exporting to external files, unlike our competition.

Kendall

 

MEC4D said:

I know that , I just wanted to have better control over the exported geometey  as I can do in Zbrush , from 1 flat poly to how many faces and segments I want and easy redone without living DS from begining to the end of the process . So looking forward to see new features and the progress 

Kendall Sears said:

MEC4D said:

That are good news Kendall, I guess I will have to switch soon to LAMH ;)  the reason I did not yet as I can do the same in other programs as I don't render anymore with 3DL, so thanks for the good news !

Kendall Sears said:

MEC4D said:

LAMH , Garibaldi or Zbrush exported OBJ are all the same geometry files, no fiber or fibre ( fiber is the actual rendered curve in each plugin or program  before exporting to obj) , Garibaldi and Zbrush exported hair have 3 side polygons option what works best in DS as it can be pretty well subdivided once for round hair tubes , more than 3 sides not recommended I don't have LAMH so I can't tell what are the setings there for export but go for 3 sides poly for best result so you can use it in scene far away not subdivided or close up subdivided and you keep the hair at the lowest poly level as you don't need more sides .

kyoto kid said:

Kendall Sears said:

kyoto kid said:

hphoenix said:

kyoto kid said:

...again Fibremesh hair is very memory intensive. It would pretty much require the memory resources of a Titan-X or even Quadro M6000 to hold a complete scene. especially with multiple characters.

It is too bad Iray didn't have a similar system to Octane where it split the Geometry and Texture load.  It wouldn't be as lightning quick as pure GPU rendering but much faster than pure CPU rendering and wouldn't require a GPU with tonnes of memory at a heavyweight price..

Actually, fibermesh hair isn't that bad.  While it is a LOT of geometry, geometry itself is a lot cheaper than image maps.  Geometry is around 32 bytes per vertex, plus Face lists (3 or 4 vertex indices per face, so about 14 bytes average).  This means that STATIC geometry (no morphs/bones) works out to about 96 bytes per face or less.  So a 100,000 face mesh would only occupy about 10MB of VRAM.  Compare this to a SINGLE 4k x 4k image map, which even at 50% compression in VRAM is 32MB.

Compared to high-res textures, geometry is cheap.  So fibermesh hair is NOT that huge of a hit, memory wise.  However, the more polys in a scene, the more ray-tests and such have to be done, so it will slow down rendering.  Complex big texture maps are just table-lookups, so are pretty fast, even with decompression.  So fibermesh hair will slow your render down, but take up only a small amount of VRAM.  Strip-based textured hair will be faster to render, but takes up a lot more VRAM.  Trade-offs.  Of course, the moment you start using fancy shaders on the hair, including transparency, special specular calculations, translucency, and more, even strip-based textured hair will start to slow down the render as well.......

But in general, geometry is a lot cheaper (memory-wise) but slower (render-wise.)

 

...if you are stuck with only CPU rendering, those render times can become glacial  Also I need to make use of what I have as being on a fixed income, I cannot afford a whole new library of Fibremesh hair content to suit various different styles and lengths.  Persoanlly I like tools such as Garabaldi and LAMH as they give me the flexibility to create any style or length I need.  The drawback with Iray is they need to be imported as a .obj, and that really does pump up the polycount. So, with textures, specularity, and translucency, you get the worst of both worlds, more memory use and longer render time whreas in 3DL they render rather quickly.

LAMH FiberHair is significantly smaller than OBJ.  Using default settings as much as 40-60% smaller on average.  Some hair styles can get upwards of 80% smaller.  But FiberHair does require the full plugin and not just the free player.

Kendall

..LAMH fibre? As I reacall LAMH isalso a strand based system (Like Garabaldi) which is why it also needs to be converted to .obj to render in Iray.

 

LAMH uses several techniques when writing out our LAMH FiberHair.  We get better definition and smaller sizes than either of the other two listed.  Our lead will increase dramatically very soon when LAMH will not need to export external files at all, OBJ format or otherwise.  And that's only one advancement, there are several more advancements that are in the pipeline to make LAMH FiberHair even more efficient.

Kendall

 

LAMH has supported OBJ since the beginning in Dec of 2012.  LAMH FiberHair feature was released not long after that.  So one could say that LAMH supported Iray before Iray was in DS.  LAMH FiberHair has always been able to be directly attached to the model in the DS viewport without exporting to external files, unlike our competition.

Kendall

 

I see.  A feature like you describe was once in a test version.  It was deemed "not useful" because flat hairs were too easy to have disappear upon camera movement.  Testing showed that no one ever played with it.  Also, the methods we use are so good that little or nothing is gained by those kinds of tricks.

Kendall

 

LAMH has better ways of handling vegetation.  We also have an extensive instancing mechanism, controllable with maps even, that has existed since day one.

Kendall

MEC4D

That is very cool I did not know that since I never used it before , one more reply Kendall with cool feature and I am going to the store hehe but when the new uograded version show up I will for sure

Kendall Sears said:

MEC4D said:

They are but not for scalp hair however great for other things , with a little twist by the root all will show up on all angles , you can use it for vegetation or for trees and there is a lot of other handy usages with one side poly fibers like leaves etc.. but for that all you need the proper control of the fibers geometry .

Kendall Sears said:

Kendall Sears said:

MEC4D said:

That are good news Kendall, I guess I will have to switch soon to LAMH ;)  the reason I did not yet as I can do the same in other programs as I don't render anymore with 3DL, so thanks for the good news !

Kendall Sears said:

MEC4D said:

LAMH , Garibaldi or Zbrush exported OBJ are all the same geometry files, no fiber or fibre ( fiber is the actual rendered curve in each plugin or program  before exporting to obj) , Garibaldi and Zbrush exported hair have 3 side polygons option what works best in DS as it can be pretty well subdivided once for round hair tubes , more than 3 sides not recommended I don't have LAMH so I can't tell what are the setings there for export but go for 3 sides poly for best result so you can use it in scene far away not subdivided or close up subdivided and you keep the hair at the lowest poly level as you don't need more sides .

kyoto kid said:

Kendall Sears said:

kyoto kid said:

hphoenix said:

kyoto kid said:

...again Fibremesh hair is very memory intensive. It would pretty much require the memory resources of a Titan-X or even Quadro M6000 to hold a complete scene. especially with multiple characters.

It is too bad Iray didn't have a similar system to Octane where it split the Geometry and Texture load.  It wouldn't be as lightning quick as pure GPU rendering but much faster than pure CPU rendering and wouldn't require a GPU with tonnes of memory at a heavyweight price..

Actually, fibermesh hair isn't that bad.  While it is a LOT of geometry, geometry itself is a lot cheaper than image maps.  Geometry is around 32 bytes per vertex, plus Face lists (3 or 4 vertex indices per face, so about 14 bytes average).  This means that STATIC geometry (no morphs/bones) works out to about 96 bytes per face or less.  So a 100,000 face mesh would only occupy about 10MB of VRAM.  Compare this to a SINGLE 4k x 4k image map, which even at 50% compression in VRAM is 32MB.

Compared to high-res textures, geometry is cheap.  So fibermesh hair is NOT that huge of a hit, memory wise.  However, the more polys in a scene, the more ray-tests and such have to be done, so it will slow down rendering.  Complex big texture maps are just table-lookups, so are pretty fast, even with decompression.  So fibermesh hair will slow your render down, but take up only a small amount of VRAM.  Strip-based textured hair will be faster to render, but takes up a lot more VRAM.  Trade-offs.  Of course, the moment you start using fancy shaders on the hair, including transparency, special specular calculations, translucency, and more, even strip-based textured hair will start to slow down the render as well.......

But in general, geometry is a lot cheaper (memory-wise) but slower (render-wise.)

 

...if you are stuck with only CPU rendering, those render times can become glacial  Also I need to make use of what I have as being on a fixed income, I cannot afford a whole new library of Fibremesh hair content to suit various different styles and lengths.  Persoanlly I like tools such as Garabaldi and LAMH as they give me the flexibility to create any style or length I need.  The drawback with Iray is they need to be imported as a .obj, and that really does pump up the polycount. So, with textures, specularity, and translucency, you get the worst of both worlds, more memory use and longer render time whreas in 3DL they render rather quickly.

LAMH FiberHair is significantly smaller than OBJ.  Using default settings as much as 40-60% smaller on average.  Some hair styles can get upwards of 80% smaller.  But FiberHair does require the full plugin and not just the free player.

Kendall

..LAMH fibre? As I reacall LAMH isalso a strand based system (Like Garabaldi) which is why it also needs to be converted to .obj to render in Iray.

 

LAMH uses several techniques when writing out our LAMH FiberHair.  We get better definition and smaller sizes than either of the other two listed.  Our lead will increase dramatically very soon when LAMH will not need to export external files at all, OBJ format or otherwise.  And that's only one advancement, there are several more advancements that are in the pipeline to make LAMH FiberHair even more efficient.

Kendall

 

LAMH has supported OBJ since the beginning in 2012.  LAMH FiberHair feature was released not long after that.  So one could say that LAMH supported Iray before Iray was in DS.  LAMH FiberHair has always been able to be directly attached to the model in the DS viewport without exporting to external files, unlike our competition.

Kendall

 

MEC4D said:

I know that , I just wanted to have better control over the exported geometey  as I can do in Zbrush , from 1 flat poly to how many faces and segments I want and easy redone without living DS from begining to the end of the process . So looking forward to see new features and the progress 

Kendall Sears said:

MEC4D said:

That are good news Kendall, I guess I will have to switch soon to LAMH ;)  the reason I did not yet as I can do the same in other programs as I don't render anymore with 3DL, so thanks for the good news !

Kendall Sears said:

MEC4D said:

LAMH , Garibaldi or Zbrush exported OBJ are all the same geometry files, no fiber or fibre ( fiber is the actual rendered curve in each plugin or program  before exporting to obj) , Garibaldi and Zbrush exported hair have 3 side polygons option what works best in DS as it can be pretty well subdivided once for round hair tubes , more than 3 sides not recommended I don't have LAMH so I can't tell what are the setings there for export but go for 3 sides poly for best result so you can use it in scene far away not subdivided or close up subdivided and you keep the hair at the lowest poly level as you don't need more sides .

kyoto kid said:

Kendall Sears said:

kyoto kid said:

hphoenix said:

kyoto kid said:

...again Fibremesh hair is very memory intensive. It would pretty much require the memory resources of a Titan-X or even Quadro M6000 to hold a complete scene. especially with multiple characters.

It is too bad Iray didn't have a similar system to Octane where it split the Geometry and Texture load.  It wouldn't be as lightning quick as pure GPU rendering but much faster than pure CPU rendering and wouldn't require a GPU with tonnes of memory at a heavyweight price..

Actually, fibermesh hair isn't that bad.  While it is a LOT of geometry, geometry itself is a lot cheaper than image maps.  Geometry is around 32 bytes per vertex, plus Face lists (3 or 4 vertex indices per face, so about 14 bytes average).  This means that STATIC geometry (no morphs/bones) works out to about 96 bytes per face or less.  So a 100,000 face mesh would only occupy about 10MB of VRAM.  Compare this to a SINGLE 4k x 4k image map, which even at 50% compression in VRAM is 32MB.

Compared to high-res textures, geometry is cheap.  So fibermesh hair is NOT that huge of a hit, memory wise.  However, the more polys in a scene, the more ray-tests and such have to be done, so it will slow down rendering.  Complex big texture maps are just table-lookups, so are pretty fast, even with decompression.  So fibermesh hair will slow your render down, but take up only a small amount of VRAM.  Strip-based textured hair will be faster to render, but takes up a lot more VRAM.  Trade-offs.  Of course, the moment you start using fancy shaders on the hair, including transparency, special specular calculations, translucency, and more, even strip-based textured hair will start to slow down the render as well.......

But in general, geometry is a lot cheaper (memory-wise) but slower (render-wise.)

 

...if you are stuck with only CPU rendering, those render times can become glacial  Also I need to make use of what I have as being on a fixed income, I cannot afford a whole new library of Fibremesh hair content to suit various different styles and lengths.  Persoanlly I like tools such as Garabaldi and LAMH as they give me the flexibility to create any style or length I need.  The drawback with Iray is they need to be imported as a .obj, and that really does pump up the polycount. So, with textures, specularity, and translucency, you get the worst of both worlds, more memory use and longer render time whreas in 3DL they render rather quickly.

LAMH FiberHair is significantly smaller than OBJ.  Using default settings as much as 40-60% smaller on average.  Some hair styles can get upwards of 80% smaller.  But FiberHair does require the full plugin and not just the free player.

Kendall

..LAMH fibre? As I reacall LAMH isalso a strand based system (Like Garabaldi) which is why it also needs to be converted to .obj to render in Iray.

 

LAMH uses several techniques when writing out our LAMH FiberHair.  We get better definition and smaller sizes than either of the other two listed.  Our lead will increase dramatically very soon when LAMH will not need to export external files at all, OBJ format or otherwise.  And that's only one advancement, there are several more advancements that are in the pipeline to make LAMH FiberHair even more efficient.

Kendall

 

LAMH has supported OBJ since the beginning in Dec of 2012.  LAMH FiberHair feature was released not long after that.  So one could say that LAMH supported Iray before Iray was in DS.  LAMH FiberHair has always been able to be directly attached to the model in the DS viewport without exporting to external files, unlike our competition.

Kendall

 

I see.  A feature like you describe was once in a test version.  It was deemed "not useful" because flat hairs were too easy to have disappear upon camera movement.  Testing showed that no one ever played with it.  Also, the methods we use are so good that little or nothing is gained by those kinds of tricks.

Kendall

 

LAMH has better ways of handling vegetation.  We also have an extensive instancing mechanism, controllable with maps even, that has existed since day one.

Kendall

 

Ruphuss

evilded777 said:

Ruphuss said:

if you are using connect you cannot alter maps in the cloud folder

you have to create a new folder somewhere else

and the whole use smaller maps for vram is not that effective as you may think

there was a comparison already somewhere in the forums

i think mec4d did it

Will the mis-information about Connect never cease to spill forth?

when i try to save an altered texture with a new name next to the old file in the cloud folder a message comes up that i am not allowed to do that

MEC4D

maybe becouse you have not the right as Administrator to do so , I have no problem  

Ruphuss said:

evilded777 said:

Ruphuss said:

if you are using connect you cannot alter maps in the cloud folder

you have to create a new folder somewhere else

and the whole use smaller maps for vram is not that effective as you may think

there was a comparison already somewhere in the forums

i think mec4d did it

Will the mis-information about Connect never cease to spill forth?

when i try to save an altered texture with a new name next to the old file in the cloud folder a message comes up that i am not allowed to do that

 

kyoto kid

Ruphuss said:

evilded777 said:

Ruphuss said:

if you are using connect you cannot alter maps in the cloud folder

you have to create a new folder somewhere else

and the whole use smaller maps for vram is not that effective as you may think

there was a comparison already somewhere in the forums

i think mec4d did it

Will the mis-information about Connect never cease to spill forth?

when i try to save an altered texture with a new name next to the old file in the cloud folder a message comes up that i am not allowed to do that

..4,9 or 4.8?

Mythmaker

Kendall Sears said:

Have you been listening in on me?  :)

In any case, most users here (on DAZ forums) are not taking the necessary steps to use their equipment properly.  The problem with running out of VRAM is that there is this crazy effort to use 4Kx4K image maps for every frikin item in a scene.  THIS IS UNNECESSARY!  

Texture Atlas is your friend.  Downsize the image maps on items that are not in primary focus.

 

OMG the first thing in my "back to Daz Studio" to do list is optimize til kingdom come. The amount of redundant 4K maps is just...world record breaking!

Even the mind-boggling number of pointless mat zones are like, WHY?  

The fiddlier the fussier the more fun??   LOL

I have no idea if surface zones adds to performance load for either iRay or 3delight but I consolidate anyway. 

Even if I had 64G VRAM and a pure Octane user, I would still trim all for tidiness and mental clarity lol. 

All the performance saving could then be spent on creating a more lively environment in which the actors/ animals do far more fun exciting things than just pouting around for fear of wrecking the stiff, perfectly posed spaghetti hair  

Mythmaker

Kendall Sears said:

LAMH has better ways of handling vegetation.  We also have an extensive instancing mechanism, controllable with maps even, that has existed since day one.

Very cool feature indeed. Couple with object instancing. Exactly the two reasons why I bought LAMH in spite of having ZBrush fibermesh obj option.

If LAMH v2 could detect/ translate any incoming instances (from ZBrush or popular standard tools) it would be amazing. Then I could still array/ nano it in ZBrush back and forth to DS. 

That said, dynamic LAMH hair drawn in iRay interactive viewport (and of cos 3delight Aux) = top  

Hiro Protagonist

Ruphuss said:

evilded777 said:

Ruphuss said:

if you are using connect you cannot alter maps in the cloud folder

you have to create a new folder somewhere else

and the whole use smaller maps for vram is not that effective as you may think

there was a comparison already somewhere in the forums

i think mec4d did it

Will the mis-information about Connect never cease to spill forth?

when i try to save an altered texture with a new name next to the old file in the cloud folder a message comes up that i am not allowed to do that

I have no trouble saving an altered texture from Photoshop in the Connect Library textures folder of a product, but when I try to load that texture on the figure Studio complains with the attached message.

This is with the current 4.9 and I think all versions of 4.9 I have tried. I created a folder for all modified textures at the root of My DAZ Connect Library, but a more sensible approach, I guess, would be to create a texture folder for that product in the runtime of a non-Connect library structure. Fiddly and annoying though.

Whatever the reason for this, it's probably not wise to store things there as you could easily lose custom textures or modified assets if they are kept in the product's Connect runtime—say if you uninstalled the product (and uninstalling Connect products is much easier to do so could be done by mistake).

wolf359

"OMG the first thing in my "back to Daz Studio" to do list is optimize til kingdom come. The amount of redundant 4K maps is just...world record breaking!"

Not surprising when you consider the target market for Daz studio
is those who create ONE single image at a time and  have little to no concern about scene optimization

And we animators are truly on our own.
 
Have a look at the newest feature list and tell me how many times  you even find the term "animation"
http://docs.daz3d.com/doku.php/public/software/dazstudio/4/new_features/start

Thankfully I render my Daz Content in a Pro application with proper Cameras,compositing tags ,Inclusive&Exclusive  Light/object relationships and scene management tools.

which is good for me because that seems to be Daz's unspoken preference  for animators
"buy our content.. but use some other program for animation creation & rendering"

Look at the choices they have made regarding Genesis3.
She imports perfectly .......into Iclone
and after a one time manual bone mapping and saving
his /her custom characterization profile from reallusion 3D Exchange, G3 like any other third party rig , is a joy to animate....in Iclone pro.

Just be prepared to render G3's animation in  Iclone or some Iclone connected engine, because if you export any of that motion back to Daz studio you get unusable rubbish.

Again thankfully I have G2 and a Massive hoard of content for that figure.

hphoenix

MEC4D said:

All I said was about is REDUCE the resolution of all maps beside Normal, Bump , Displacement and Opacity as they need to be in higher resolution , also Bump, Specular and Opacity maps saved as grayscale will reduce the size as they are float maps and not color . If you render full figures in HD format images you not need more than 2000x2000 for color maps and that will cut the vram usage in half already , load faster in general , I wish we have an option for texture resolution the way HD environment have under Interactive mode in iray in place of the compression 

 

Just as a note....ALL images internally in Iray are stored (and compressed, if applicable) as 32-bit RGBA raw images.  This means there isn't any savings for float maps, as they will be converted to full RGBA at load.

They are faster to index and process and compress/decompress that way, but do consume more memory.

So ALWAYS resize the images if you do NOT require that high of a resolution.

 

nonesuch00

Well I thought they when updating Cararra to work with Genesis 3.

As far as this iRay goes I like very much how it causes the characters skin to react properly to lighting changes but the rendered iRay skins invariable look much tanner then they are intended to when rendered, even for characters that are supposed to be tan, unless it's a very, very tan character, that's tan enough to hide this iRay darkening effect.

I will soon try iFlake, clearly that is a character that is both untanned and has iRay shaders, and see how those textures render in iRay.

Oso3D

My advice is to tweak translucency color. I've found that can radically change the tone of Iray Skin. If the result is tan, try shifting translucency color to a light pink. Also be sure the base color is pure white, because chances are good the base texture is a bit over saturated and dark.

MEC4D

Do you have some link to info about that ?  I would like to check since when I used 32-Bit maps as textures for some early testing the vram memory was huge and eventually DS crashed on me, other way it shouod make no difference I guess so I would like to learn about it , I know that it process the maps per pixel as all GPU render engines do but converting float maps into color maps and back to float maps by the shaders is kinda chaotic process

hphoenix said:

MEC4D said:

 

Just as a note....ALL images internally in Iray are stored (and compressed, if applicable) as 32-bit RGBA raw images.  This means there isn't any savings for float maps, as they will be converted to full RGBA at load.

They are faster to index and process and compress/decompress that way, but do consume more memory.

So ALWAYS resize the images if you do NOT require that high of a resolution.

 

 

Kendall Sears

hphoenix said:

MEC4D said:

All I said was about is REDUCE the resolution of all maps beside Normal, Bump , Displacement and Opacity as they need to be in higher resolution , also Bump, Specular and Opacity maps saved as grayscale will reduce the size as they are float maps and not color . If you render full figures in HD format images you not need more than 2000x2000 for color maps and that will cut the vram usage in half already , load faster in general , I wish we have an option for texture resolution the way HD environment have under Interactive mode in iray in place of the compression 

 

Just as a note....ALL images internally in Iray are stored (and compressed, if applicable) as 32-bit RGBA raw images.  This means there isn't any savings for float maps, as they will be converted to full RGBA at load.

They are faster to index and process and compress/decompress that way, but do consume more memory.

So ALWAYS resize the images if you do NOT require that high of a resolution.

 

Are you sure about this?  I seem to remember contrary info from the nVidia Beta/Developer forums.

Kendall

MEC4D

I just checked , GPU vram jump on when using different images at the same resolution , I set compression off under render setting , and it does exactly as I though .  I am also member of the Nvidia Developer program 

and never saw any info about iray doing it other than per pixel but not converting float maps into color as it would make no sense as the MDL use float maps and color maps for processing 

anyway here my test I just did of the vram usage with different maps