PDA

View Full Version : Hyper Voxels 2.1!



Mr Rid
11-25-2011, 07:47 PM
NT is a shameless tease. I just discovered I can actually open the old voxel menu in 10.1 (have not been able to since v6 or 7). Its very glitchy but I can barely set up old school HVs. It renders as slow as always. Steamer still wont let me in. :(

99819

Some weeks ago I was able to load some old Steamer and HV2 scenes in LW9.2 (could not open menus). But they dont appear to render right in 10.1. I still miss the softer volumes I could get more easily then.

jwiede
11-25-2011, 08:31 PM
The scary thing is how much of the volume of overall code included is comprised of stuff like this (incl. ancient bugs, etc.).

One caution: I'd be very careful about quitting and restarting after accessing such old cruft before working on any scenes/work you actually value, as you never know just what even opening them in current LW might break behind the scenes.

stiff paper
11-26-2011, 03:35 AM
@Mr Rid

When you say "Softer volumes", you don't mean the surface voxel blending mode, do you? I only ask because the missing blending control is one of the things they've put back into 11 (apparently).

Given that it might have been mostly your comments in the past that persuaded devl to fix the blending mode, maybe you should give this a bit more detail, because, well, you never know...

Mr Rid
11-27-2011, 05:23 PM
The ball-blend is only part of it (there still needs to be distance between particle grads on all axis). But there was less finagling to get soft cloud volumes with old HVs, and particularly Steamer. The only way I get the same look now is by combining both volumes and sprites, and post processing

erikals
11-27-2011, 10:30 PM
you should be able to get similar style with Ogo Taiki... ($30) (and maybe LW11, haven't checked)
http://www.youtube.com/watch?v=oW0ImR2zZ9M
http://forums.newtek.com/showthread.php?p=1003995#post1003995

Phil
11-28-2011, 08:45 AM
you should be able to get similar style with Ogo Taiki... ($30) (and maybe LW11, haven't checked)
http://www.youtube.com/watch?v=oW0ImR2zZ9M
http://forums.newtek.com/showthread.php?p=1003995#post1003995

I had the impression that Taiki was abandoned. I haven't seen any movement on it for years now.

erikals
11-28-2011, 09:00 AM
i bought it april 2010, so, it works fine, like seen in the video :]

maybe not developed, but not abandoned

netstile123
11-28-2011, 09:48 AM
bugy al right.. I can't even get it to work,

erikals
11-28-2011, 09:51 AM
taiki, HV2.1 or LW11 ?

bazsa73
11-28-2011, 10:07 AM
hm, OGO taiki looks good but by this time we should have had it natively implemented in Lightwave. Somehow I am not too impressed yet with the newly implemented blending features. I want more. More fluidlike but faster. These are exactly the fields where NewTek should excel the concurrence. Providing faster, better, easier solutions than the big "evil" and the rest. But this is just a wish. I'm in patience.

erikals
11-28-2011, 11:25 AM
this is darn fast btw,...
http://youtu.be/cg8w8AVzsO8

 

Netvudu
11-28-2011, 11:57 AM
erikals, thatīs a nice Taiki example...but Iīm wondering, how come it looks faster in VPR than the final render? whatīs the difference...antialiasing?


EDIT: wait...is it just 32-bits, or is there a 64-bits version?

bazsa73
11-28-2011, 12:33 PM
Cheaper too, right? ;)

Quality, Speed, Cost - as always, pick 2. LW is in the cost/speed area, so high end features (or no doubt many features that have become 'standard features' in more expensive apps, which means it's still high end from the LW perspective) should not be expected.

I'm skeptic too but still I believe. Otherwise existence would be unbearable :)

geo_n
11-28-2011, 12:40 PM
this is darn fast btw,...
http://youtu.be/cg8w8AVzsO8

 


So it still works in 10.1. Have you tried it in 11?

erikals
11-28-2011, 12:43 PM
erikals, thatīs a nice Taiki example...but Iīm wondering, how come it looks faster in VPR than the final render? whatīs the difference...antialiasing?

EDIT: wait...is it just 32-bits, or is there a 64-bits version?

well it's not "just" 32bit, that's a misconception, 32bits is usually faster than 64bit, my main render is 32bit.
VPR is faster as of a mix of compression and somewhat lower quality afaik...
but the result speaks for itself i think, VPR is great in this case...

here's a 15min VPR render, rendered with "make preview"
this render can then be composited in post

erikals
11-28-2011, 12:53 PM
works in 10.1, haven't got 11 just yet...

wouldn't really matter too much to me if it was for 10.1 only, i'd just use 10.1, no problemo.

i've learned that keeping previous LW versions is a smart thing to do.
and for stuff like Ogo Taiki it's not vital that it works in LW11, as one wouldn't use it too much, just in special cases...

but i have no idea, might work in 11...

Netvudu
11-28-2011, 06:54 PM
I understand...the problem being is I havenīt installed a 32-bit version for any CG app for the last 2 years or so. Donīt think Ogo Taiki is going to change by itself. That stuff you rendered is fast indeed, although the animation shows some of the problems of VPR rendering (i.e. low sampling).

erikals
11-28-2011, 08:18 PM
well, i used the lowest quality for both the volumetrics and the VPR,
so the quality is quite good imo, the test i posted here lies a bit as it's blurry.
crank up the volumetrics / VPR settings and it will be quite nice.

erikals
11-28-2011, 08:25 PM
please do note though that i don't find Taiki the solution,
but rather a nice addition to HVs and Turbulence4D. (and it's only $30)

Netvudu
11-29-2011, 04:44 AM
I agree. If I had 32-bit versions in my daily pipeline I would probably add it as a little extra.

erikals
11-29-2011, 09:00 AM
hm, found a bug when making a new emitter,

edit: current fix / workaround is to edit the old saved scene...

Mr Rid
11-30-2011, 04:46 PM
A few years ago I worked on a project where we evaluated all the cloud options for LW. I wasted time in Ozone which was too glitchy and limited. Another guy played with Ogo, but found more practical results out of Terragen. I dont recall exactly why, but it was easier to get variations to show a picky client.

Was just browsing some interesting Terragen renders:

Cumulous pack (no post processing)- http://www.nwdanet.com/images/phocagallery/cumuluspackV3/rising%20cumulonimbus%20render%20b.jpg

'real or fake'
http://nvseal.deviantart.com/gallery/?offset=24#/d23yn1x

Nice gallery- http://www.nwdanet.com/galleries/category/31-frank-gallery
particular- http://www.planetside.co.uk/gallery/f/tg2/FrankB_close+up+8b.jpg.html

Follow terrain animation- http://www.youtube.com/watch?v=pMBQnOaxP-w&feature=related

Hi res planet cover- http://nvseal.deviantart.com/gallery/?offset=0# - "Terragen Soft Clouds 2"

Hurricane- http://www.nwdanet.com/galleries/category/29-nvseal-gall

http://buzzzzz.deviantart.com/gallery/ - "Wizards Watch"

Another nice gallery- http://freelancah.deviantart.com/gallery/

Mr Rid
11-30-2011, 04:58 PM
This was useful in HV299937

An important feature that has been missing (also in FiberFX I just noticed) is the ability to render a holdout, or HVs as black in the alpha as you can with objects. If you normally separate elements for comp, and an object renders in mixed depth with HVs then the only way to make a holdout is to fake one in a separate color render with HVs colored white with black objects.

erikals
12-01-2011, 12:32 AM
looked alot at Terragen 2 some time back, it creates some alright results, but unfortunately not all that much better than Taiki, and Taiki is $30 while Terragen is $400...

i like the hard puffy style that Terragen can give, even though it still lacks realism.

also earth seen from space is nice in Terragen, though i've seen "hand-made" native LW scenes that have rendered better...

so, imo we're still where we left off years ago as far as clouds go.

unfortunately :]

prometheus
12-01-2011, 04:46 AM
Im in the mood of experimenting with some hv clouds at the moment, Iīll try and post some images either today when I get home or tomorrow, I wouldnīt do this if It werenīt for the VPR wich allows for easy tweaking.

well terragen, I tried it some times, but absolutly horrible in getting a good fast preview on the atmosphere with clouds, sooo slow.

But..the cloud fractals are way much better than those noise functions for vue, mainly because that terragens cloud fractals seems designed for just that, where vue has old noise functions mainly designed for landscapes not clouds.

Then terragens final renders seem to have a better noise reduction and better color profile output.

However..I think I would choose vue 10 inspite of all that, the ease of use and speed compared to terragen and all features are worth more.

Most of all I would like to have a revamped ogo taiki thou..inside of lightwave..if the air properties would be improved similar to the spectral atmosphere in vue, and ease up on the interface and some speed enhancements, then ozone would fall flat.

I have to check my purse after I have bought lw11 thou.

Michael

monovich
12-01-2011, 03:39 PM
I recently saw a great solution done for the clouds in Paths Of Hate. Check these links out:

http://www.flickr.com//photos/motionographer/sets/72157627568074796/show/

snipped from motionographer interview:


MAKING CLOUDS

The cloud sets were definitely the most difficult and challenging elements to create in this film. The development of a technology which would allow the creation of stylized, pictorial clouds took me over a year. It is always difficult to create clouds in 3D, especially if you want them to look photo-realistic. Having them realistic and stylized at the same time was even more difficult.

The dogfight choreography and camera animation in Paths of Hate are very spacious and dynamic, so the cloud sets had to be completely three-dimensional. There was no way to use any kind of half measure such as flat, matte-painted plates or stock shots. I also wanted to have full control over the shape and lighting in my clouds.

I developed a complicated technique that uses an old and forgotten vertex color in 3DS Max, one of the oldest tools in there. Using vertex color I was able to create and illuminate fake translucency and have full control over these clouds. The whole trick was to use old, simple tools in a new way.

The greatest thing about this technique is the render time. For one 2K frame it took less then 30 seconds to render.

http://motionographer.com/features/damian-nenow-at-siggraphpaths-of-hate/

prometheus
12-02-2011, 04:50 AM
That was great monovich..

looking good except for some banding artifacts in some perspectives.

cool is that you get a sort of cloud feedback with geometry first when animating the plane paths, and that it obviously renders fast.

Now...anyone care to translate this tutorial to lightwave? If possible?

I wonder how to set that up with vertex maps data to feed in to luminosity and translucency channels, i suspect that is required to use some of dponts nodes?
Edit ...the artifacts may infact by something that was to stylize the whole scene?

Michael

Netvudu
12-02-2011, 05:34 AM
I attended to that conference at Autodeskīs booth at Vancouverīs Siggraph. I think about 80% of the method is easily transferable to Lightwave but there are a couple of gotchas Iīm not that sure about how to do.
I would like to give a try in the next days. Problably I would have to render some sort of translucency and bake it into a vertex color map....mfff, I will have to tinker with this...

jlp.media
12-02-2011, 06:43 AM
I couldn't agree more...thanks Monovich for the great reference material. I hope to god he didn't manually Boolean each cloud cluster. Now that I think about it, I wonder if there's a way to batch Boolean in LW???
I know that the point clone plus tool and point normal move tool would be perfect for making that box shaped cloud.

monovich
12-02-2011, 09:46 AM
Well now that I'm thinking about this I'm super curious if its do-able. Seems like something to do with Metaballs?

I'm going to give it a shot right now. What the heck... its Friday.

dwburman
12-02-2011, 09:57 AM
I actually had a go at converting that technique to LW, but didn't quite finish it. Instead of baking to the vertex color, I baked to a UV map. It sort of worked, but I think I need to make a version with more cards.

Metaballs worked well for making the clouds.

I had to use one of the Kappa legacy SSS shaders on the clouds since the new SSS didn't work right with the surface baking camera (or was that the surface baker filter?).

bazsa73
12-02-2011, 09:57 AM
I have seen that video too and was thinking if it's possible in LW.

nikfaulkner
12-02-2011, 10:25 AM
i've used an old cloud generator script in blender to make boards.

uv'd, surfaced and then rendered in lightwave. works well (if a little convoluted) very fast renders and you can make clouds to exact shapes easily and see them in layout.

see my old post

http://forums.newtek.com/showpost.php?p=966129&postcount=1

monovich
12-02-2011, 10:55 AM
I can't figure out a way to get the vertex color data onto the HV sprites.

When I click "use particle color" where does it get that particle color from? It definitely doesn't take it from the mesh. I tried using a particle emitter but can't find where to set the particle colors in the emitter.

I tried using Node texture in HV color panel and then using Vertex Color plugged into color but that didn't work either.

prometheus
12-03-2011, 07:00 AM
I can't figure out a way to get the vertex color data onto the HV sprites.

When I click "use particle color" where does it get that particle color from? It definitely doesn't take it from the mesh. I tried using a particle emitter but can't find where to set the particle colors in the emitter.

I tried using Node texture in HV color panel and then using Vertex Color plugged into color but that didn't work either.

Uhhmm..Ivé done that before I think, but rarely used and I donīt remember how to set that up correctly, have to check that again.

but check this image..
and under the deform tab/add displacement where the hv particles are, you need to double click it to gain acess to set particle color and the color vmap., but you of course need to create on too in modeler.
bad interface to hide that feature thou.

Michael

prometheus
12-03-2011, 07:53 AM
uhmm..I painted a vertex color map, and I can get it to show on the opengl viewport on a subdivided grid with hv sprites..but it wonīt show up on viper, vpr or final render..

Must be doing something wrong when creating the vertex map when I paint the vertex map in modeler?

Michael

prometheus
12-03-2011, 08:23 AM
Cool! Thanks Michael, it works, and you're absolutely right - great place to hide it. :)
Now the only thing missing is how to get the Surface Baker to see some of the SSS Materials... for now it does not write vertex colors if they're set up with Nodes, let alone need preprocessing... :(

He..well good for you, but I suddenly canīt get it to work, my vertex painted map wonīt show up in renders or viper, but they are there on the open gl viewport on the hv sprites..so what are you doing right and I am not?..hmm.

Michael

prometheus
12-03-2011, 08:44 AM
Oh, I see... I had 2 maps with the same name... wonder when that happened? Something does not quite work here either. *grmpf*
BTW, didn't HV render a sprite to every vertex before, even for SP objects? I didn't use it for some time, but didn't it respect the SP level too?

EDIT: I was giving that technique a try a few weeks back, but was stuck at how to assign Vertex Colors to sprites... now I don't even get a correct Vertex Map baked...


Well..Itīs a little strange that the color vertex map shows up in open gl with hv sprites on vertices, but not in viper,vpr and rendering..I think I need to give it a rest for a while until figuring that out.

and for sp? subpatch objects, yes hv sprites will respect those settings, and if you work with vpr o viper and increase the resolution of subpatch objects ..then you will have more density of vertices/hv "particles"

VPR and viper recognizes the display subpatch level, not the render subpatch level.
but for final render you always need to match the render subpatch levels.

I used the subpatching setting for these old experiments.
http://vimeo.com/1539143

Michael

prometheus
12-03-2011, 09:07 AM
I think I solved it kind of.

for rendering ordinary polys and surfaces, the diffuse channel gets dumped to 0 ..so that needs to be readjusted it seems.

for rendering of hv sprites, I found that I needed to increase luminosity values extremly, setting it to 1000, or increase density..se image.

if you render sprites on object vertices, remember to set the object dissolve to 100% in the objects render properties panel.

Michael

prometheus
12-03-2011, 09:43 AM
[QUOTE=Oliver;1202635]I found out something profoundly! If I don't have a SP object, editing the SP level does not have any effect! :D In other words: D'oh! :bangwall:
Anyway...

Lol..nice find:D

I tried with a SP object, but with that HV does not accept the Vertex Color Map. So I guess that is probably in the direction of your problem?
__________________________________________________ __________________________________________________ _____________________

No..the problems seems fixed now, I found that the luminosity or density values was just reduced when creating a vertex paint map, probably because of how you set the painted vertex maps colors or lights...thatīs why I thought they didnīt show up in renders ..but in fact they were there, and increasing luminosity or density makes them show up.

And no..I tried with subpatch objects as well..and it works okay here, so it works..youre a little wrong there I think.

Note that if you switch between maps under the deform tab and hv particles set color, you need to uncheck and check again for it to update properly.

See my images and youīll see that it works with subpatch objects.
different subpatch levels..color information is only a painted vertex map.
when setting higher subpatch levels ..it will be needed to lower density or luminosity to get a good look.

Michael

prometheus
12-03-2011, 10:23 AM
I was trying out particle clusters done with some motion and wind settings..and freezing them, saving out as transformed object, and in modeler create a vertex paint map..

Seems to be working quite okay, so this means you can paint outer particles in a nebula cluster with special dedicated colors and the inside or other parts exactly as you want the color to be.

creating several types of wind affected partigons and then cloning particle clusters and then in layout merge them could probably be cool looking.

Michael

Thomas Leitner
12-03-2011, 12:17 PM
- we can't bake SSS vertex maps
hi,
you can bake the surface (with any node setup) with the surface baking camera to UV map and use this map in modeler to colorize the vertices:
Map > Color > Textured Point: choose the UV map as Texture and a vertex map to use it.

ciao
Thomas

Mr Rid
12-03-2011, 04:11 PM
Well..Itīs a little strange that the color vertex map shows up in open gl with hv sprites on vertices, but not in viper,vpr and rendering.....


Havent tried in v10+ but some of the distance between particle grad channels worked in GL but not in render. Also reminds of a FiberFX bug I just encountered- if I load-from-scene anything into a FFX scene, it blows away FFX (disappears from pixel filters & cant be re-added, wont render in VPR or F9) yet fibers continue to draw in GL. I have to reopen scene, re-add ffx, & reload settings. Regularly I run into a PFX situations that just wont calculate or render right until I reopen scene.

monovich
12-06-2011, 11:28 AM
Oh boy Oliver looks like you got there!

Have you tried using the advanced camera instead of the surface baking camera? I don't know how to properly set it up but it can be used to surface bake as well, yes? And it seems to have quite a few more options.

What would be great is to avoid baking to the vertex color map all together and just have the HV's sample the color/luma from the nearest point on their emitting mesh at render time. That way you have an ultra lowres mesh for the clouds which is used to process all of the lighting, then the HV's just pick up that info and make it look like a cloud. That way everything stays in layout and is much more interactive.

monovich
12-06-2011, 11:42 AM
well shoot. all I was missing was Prometheus' step for activating particle color via displacement panel. Viola! instant realtime cloud. Cool!

bazsa73
12-06-2011, 11:48 AM
Interesting thread indeed. I cant participate right now because I work on smg :(

monovich
12-06-2011, 01:39 PM
I used almost the same technique as you, but my cloud has more even lighting (shadows aren't as dark) so the effect is less pronounced.

1. light base object
2. surface baking camera to UV
3. textured point to vertex color map
4. vertex color to HV sprites.

I'm sure SSS gives a nice look, but I wonder if its overkill. The general internal scattering of a cloud can be pretty easily faked at these resolutions.

edit: attached examples show it better.

monovich
12-07-2011, 09:14 AM
Good to know that the baking shader can bake to a vertex map. I learn so many new things every day here.

Netvudu
12-07-2011, 11:40 AM
mono, I said that two pages ago! ...oh,well...
hey bunch, Iīm so happy you deciphered this! The step I was missing was using Textured Point to pass the color from the UV to a vertex color map.
I have to try this.
I also agree a faster solution than SSS might also work depending on the look...maybe undust ChanLum nodal stuff? its ages since I last used it!

Hieron
03-22-2012, 02:50 PM
BTW, fooling around in 11, I built a sprite by hand (flat poly with a simple procedural and a falloff) and instanced that to the vertices in 11 (or using DP Instance)... baffled I realized that all that was missing was a way to connect the vertex color information of a different mesh to the Instance Color gradient... guess I'll ask Denis if it would be possible to use the VMaps of one object in the surface tree of a different one. It's not right now, but maybe he can create a "item VMap node"? Looking forward to the global node graph coming soon (12? 13?). :)



Ok, it is a bit of a trick, and it does need a DP node ofc:

102878

But that is a VMap on the plane mesh driving the colors (can drive anything surface related) of the instanced poly's :)
And it didn't need LW 13 :P (but I surely would like that global node graph.. and native node nesting while at it :P)

dwburman
03-22-2012, 05:19 PM
Sorry for resurrecting an old post, but I lost track of this thread until someone else posted in it recently.



So we know:
- we can use Sprite Vertex Coloring only with non-SP objects.
- so we can't upres the Sprite number by setting SP levels.
- we can't bake SSS vertex maps (most likely because baking this kind of information needs a camera POV, and Surface baking is in LW solved by having a camera trace the surface of the object, thus all shaders depending on viewing angles can not work).


Did you try using the Kappa legacy SSS shader? In my experiments, Kappa was the only SSS shader that wasn't a solid color when I tried to bake it.

Hieron
03-22-2012, 05:49 PM
Sorry for resurrecting an old post, but I lost track of this thread until someone else posted in it recently.



Did you try using the Kappa legacy SSS shader? In my experiments, Kappa was the only SSS shader that wasn't a solid color when I tried to bake it.

I just baked using SSS 2... (using camera baker), but it only worked at 640x640 pixels.. (1024x1024 etc didn't work)..

I've always thought the bakers (shader or camera) were buggy...