TrueArt's Batch Baking Camera v1.0 has been released!

[Sensei]

Hello!

I would like to inform that our new plug-in TrueArt's Batch Baking Camera v1.0 has been released!

TrueArt's Batch Baking Camera is LightWave v9.6+ Layout plug-in to automatically baking objects surfaces.

In LightWave v9.0 there was introduced custom camera plug-in class, and one of kind is Surface Baking Camera for baking object surface to image file. But to function correctly it requires to open user-interface for every single object and picking up item and uv map from drop-down list then pressing Render Frame (or F9 key) and saving rendered image on disk. When you have to bake hundred or thousands of objects, so simple task quickly becomes real pain taking many hours.

That's why we have made our TrueArt's Batch Baking Camera to greatly simplify this unpleasant process and make use of full power of renderfarm in baking surface.

Unlike Surface Baking Camera, our Batch Baking Camera doesn't require to set any item or uv name. Instead it completely automatically assigns the all active objects to frames in animation. Therefore it allows using Render Scene command (F10 key), or sending whole scene to renderfarm and render hundred or thousands object surfaces in one single key press.

TrueArt's Batch Baking Camera key features:

* Very efficient regular rendering. With UV Border option set to 0% tests showed 225% speed-up in comparison to LightWave's Surface Baking Camera (example 220,000 polygons object).
* Very effiecient UV Border rendering. The bigger value, the faster rendering than original LightWave (in which it quickly goes through the roof).
* More accurate UV Border support. Original LightWave often renders UV Border with dots (color taken from environment set in Effects > Backdrop window).
* Rendering by Render Scene command.
* Rendering by ScreamerNet or other Renderfarm Controller.

To read more please visit our website:
http://batchbakingcamera.trueart.eu

Best Regards!

[JohnMarchant]

Hello!

I would like to inform that our new plug-in TrueArt's Batch Baking Camera v1.0 has been released!

TrueArt's Batch Baking Camera is LightWave v9.6+ Layout plug-in to automatically baking objects surfaces.

In LightWave v9.0 there was introduced custom camera plug-in class, and one of kind is Surface Baking Camera for baking object surface to image file. But to function correctly it requires to open user-interface for every single object and picking up item and uv map from drop-down list then pressing Render Frame (or F9 key) and saving rendered image on disk. When you have to bake hundred or thousands of objects, so simple task quickly becomes real pain taking many hours.

That's why we have made our TrueArt's Batch Baking Camera to greatly simplify this unpleasant process and make use of full power of renderfarm in baking surface.

Unlike Surface Baking Camera, our Batch Baking Camera doesn't require to set any item or uv name. Instead it completely automatically assigns the all active objects to frames in animation. Therefore it allows using Render Scene command (F10 key), or sending whole scene to renderfarm and render hundred or thousands object surfaces in one single key press.

TrueArt's Batch Baking Camera key features:

* Very efficient regular rendering. With UV Border option set to 0% tests showed 225% speed-up in comparison to LightWave's Surface Baking Camera (example 220,000 polygons object).
* Very effiecient UV Border rendering. The bigger value, the faster rendering than original LightWave (in which it quickly goes through the roof).
* More accurate UV Border support. Original LightWave often renders UV Border with dots (color taken from environment set in Effects > Backdrop window).
* Rendering by Render Scene command.
* Rendering by ScreamerNet or other Renderfarm Controller.

To read more please visit our website:
http://batchbakingcamera.trueart.eu

Best Regards!

Sensei i sent you an email about 64 bit versions of a couple of plugins you have. Will there be 64 bit versions of this one.

Regards John

[Sensei]

UV border would make more sense in pixels though. Pixels are the standard for game baking padding. Usually an 8 pixel border.

It's easy to go from pixels to percents when you know width of rendered image- 8*100/width= Batch Baking Camera's UV Border. You can enter it as expression and LW will give you right value.

Plug-in calculations are all in UV space, so in range 0.0-1.0, where is no knowledge about pixels..
Maybe LightWave's Surface Baking Camera, cast everything to XY immediately, and that's why it has this option given in pixels?


what would be nice is for there to be a filter that could be used so only UV's named the default "UV texture" or your own naming convention such as "Bake" etc would be baked and others ignored.

I like it and easy enough to implement. Will add to TODO list. Two text fields, one for item name and second for uv name. Coma separated portions of names.

[Sensei]

Benchmark made on Core i7 930 2.8 GHz, LightWave v9.6 build 1539 32 bit.

Output 512x512, 1 AA pass, UV Border 0

2600 polygons object Spherical Mapping, filling whole UV space
Batch Baking Camera 0.6 second (250% faster)
Surface Baking Camera 1.5 seconds

2600 polygons object Atlas Mapping
Batch Baking Camera 0.4 second (275% faster)
Surface Baking Camera 1.1 seconds

210,000 polygons object Spherical Mapping, filling whole UV space
Batch Baking Camera 1.6 seconds (235% faster)
Surface Baking Camera 3.8 seconds

210,000 polygons object Atlas Mapping
Batch Baking Camera 1.4 seconds (228% faster)
Surface Baking Camera 3.2 seconds



Output 1024x1024, 9 AA pass, UV Border 0

2600 polygons object Spherical Mapping, filling whole UV space
Batch Baking Camera 12.8 seconds (209% faster)
Surface Baking Camera 26.8 seconds

2600 polygons object Atlas Mapping
Batch Baking Camera 7.0 seconds (227% faster)
Surface Baking Camera 15.9 seconds

210,000 polygons object Spherical Mapping, filling whole UV space
Batch Baking Camera 16.6 seconds (210% faster)
Surface Baking Camera 34.9 seconds

210,000 polygons object Atlas Mapping
Batch Baking Camera 10.1 seconds (206% faster)
Surface Baking Camera 20.8 seconds

[roctavian]

Looks really impressing.:thumbsup:
Constantly 2 times faster comparing with surface baking camera. Both with continuous and discontinuous UVs. How was the object textured? Procedurals and especially nodes are taking much longer to render than bitmaps. I suppose is the same with the Batch Baking Camera.
The formula 8*100/width= Batch Baking Camera's UV Border is for 8 pixels border? If I want 20 pixels border I will use 20*100/width?


I like it and easy enough to implement. Will add to TODO list. Two text fields, one for item name and second for uv name. Coma separated portions of names.

:agree: it will make things easier.

For a modeling plugin is fine to have only a 32 bit version (not ideal but eventually it will do the job). But for a layout plugin is not good enought. I think a 64 bit version is a must. Really.
Looking forward for the 64 bit version.

[Sensei]

Looks really impressing.:thumbsup:
Constantly 2 times faster comparing with surface baking camera. Both with continuous and discontinuous UVs.

Whether UVs are continuous or discontinuous really doesn't matter. Unlike regular ray-tracing rendering, baking process is storing this information at startup reading each polygon's point uv once and storing in internal buffers. It's later used for optimizations, so not all polygons are scanned and checked whether they are inside of uv at spot x,y (these optimization speed up baking example 210,000 polygons 12,300% (123x), I have checked in plug-in development)

How was the object textured? Procedurals and especially nodes are taking much longer to render than bitmaps. I suppose is the same with the Batch Baking Camera.

In example there was used simple procedural texture. Benchmark has to show difference between Batch Baking Camera and Surface Baking Camera, not time of rendering other elements. Huge time of rendering complex node setup would influence both cameras the same level, because there is exactly the same number of pixels and samples to calculate in both cases.


The formula 8*100/width= Batch Baking Camera's UV Border is for 8 pixels border? If I want 20 pixels border I will use 20*100/width?


Correct.
border/width gives value between 0.0-1.0. Then multiplying it by 100 gives percent. It can be entered as expression and LightWave will calculate it automatically.

[GraphXs]

Nice plugin, to bad it doesn't allow for multiple types of render buffers.(Complete, Diffuse, Normal, AO,GI, Spec, Ref,etc.)
Is it possible to add a function for that? And it would just add the type of map rendered at the end of the name? I wish LW had a Render buffers to texture?

Also can it render overlapping polys in the UV space correctly. It would also be nice it cany only render half the model or see that it has shared overlapping UV's and ignore one side. (I don't believe any UV backing tool does this?

[Sensei]

Nice plugin, to bad it doesn't allow for multiple types of render buffers.(Complete, Diffuse, Normal, AO,GI, Spec, Ref,etc.)
Is it possible to add a function for that?

Camera class by itself has no control over what is rendered. It is just controlling source of ray and direction in which it's fired, and basic RGB filtering. Of course I can add another custom image-filter to the next version of plug-in. And Rename Button will automatically handle these files too.

Generating other buffer types without auto renaming is as easy as adding appropriate image filter in Effects window. Then you will have bunch of files like diffuse0001.png, diffuse0002.png etc. Corresponding to different objects with different uv maps.

If you need renaming feature, I see workarounds:
- Render with one of image-filters, then select f.e. diffuse0001.png in Render Globals > Output. Press Batch Rename (it always work with what is set as RGB Prefix in Render Globals). Select specular00001.png in RG and again Batch Rename etc with other. And all channels whole image sequences will be renamed.
- connect f.e. AO node to Diffuse Shading in Node Editor of surface, then mine SpreadSurface to copy settings to the all objects in scene, then F10, and press Batch Rename.
- If you will use LightWolf's OpenEXR, then you will have embed multiple buffers in single file. Just set Pattern to %s%04ld.exr and press Batch Rename, and they should be handled.


Also can it render overlapping polys in the UV space correctly. It would also be nice it cany only render half the model or see that it has shared overlapping UV's and ignore one side. (I don't believe any UV backing tool does this?

It's not possible to have overlapping polygons, because how?!
That's not possible from logical point of view.

Of course it can analyze and report badly overlapping polygons showing error window..

[Cageman]

Cool initiative...

I would like to see some videotutorials/demos with this in action before I decide wether to buy it or not. Or, even better... a timelimited trial version....

[Cageman]

Nice plugin, to bad it doesn't allow for multiple types of render buffers.(Complete, Diffuse, Normal, AO,GI, Spec, Ref,etc.)
Is it possible to add a function for that? And it would just add the type of map rendered at the end of the name? I wish LW had a Render buffers to texture?

Hmm... if you use Surface Baking Camera and enable renderbuffers, those renderbuffers will be rendered the same way the Surface Baking Camera renders. I don't see why this wouldn't be true with this Batch Baking Camera.

[Captain Obvious]

One thing worth noting regarding the render time comparison is that the difference will be SIGNIFICANTLY reduced when rendering complex shaders. The surface baker camera has a problem with multi-threading. It's been a while since I looked into this, so I can't remember the details so well anymore, but it seems that the process of converting pixels in the output image to UV coordinates and then world space coordinates is A) VERY slow and B) single-threaded. if you render a simple object with the surface baking camera and LOADS of anti-aliasing samples, you will spike one hardware thread and leave the rest unused. However, if you render something with very complex shading and just one AA sample, CPU utilization is very high and relative efficiency is much higher.

The performance increase Sensei quotes is based on very simple shading.


Nice plugin, to bad it doesn't allow for multiple types of render buffers.(Complete, Diffuse, Normal, AO,GI, Spec, Ref,etc.)
Is it possible to add a function for that? And it would just add the type of map rendered at the end of the name? I wish LW had a Render buffers to texture?
It should work fine to render out diffuse, normal, AO, etc, if you use something like exrTrader.

[Sensei]

It should work fine to render out diffuse, normal, AO, etc, if you use something like exrTrader.

That's the only part of this message I can agree..

[Lightwolf]

However, if you render something with very complex shading and just one AA sample, CPU utilization is very high and relative efficiency is much higher.
True. On the other hand, that native Camera also doesn't scale well the more threads you use, even if the surfaces are complex. Which means you effectively get less of a speed-up using more threads. Heck, I wouldn't even be surprised if there were cases where you get no speed up or even a slow down in a worst case scenario.

Cheers,
Mike

[roctavian]

Heck, I wouldn't even be surprised if there were cases where you get no speed up or even a slow down in a worst case scenario.

I experienced that and is sooooo annoying. I was never able to track down the source of this evil behaviour.
And if you top-up the pixel border issues with the baking camera, this plugin is really useful. :thumbsup:
Again, looking forward for the 64 bit version.

[Captain Obvious]

That's the only part of this message I can agree..
Render with the standard baking cam on a multi-core machine with simple shading / lots of AA and you get crap CPU utilization. Render on the same machine with little AA / complex shading, and you get good CPU utilization. If you disagree, then I'd like to see it backed up with more details. As I said, I've done some pretty extensive testing on this subject. :)

How about this? Bake an object with 30 AA samples and an AO shader with 8 rays. Then bake it again with just one AA sample and 240 rays in the AO. The total amount of AO samples ends up being the same, so noise levels should be comparable. If we ignore aliasing, quality should be about the same. Do this in both the standard, and in yours. Compare performance. Oh, and then do it all again with just ONE thread enabled. :)

I did plenty of tests with this and an in-house baking camera a while ago (one that was not too dissimilar to yours, I guess). The biggest speed difference I was able to get between the in-house and the standard one, was about 7–8x (on an eight core workstation). I don't think I ran any tests with border expansion, mind you. However, when I then proceeded to bake some of our more complex shaders, the performance difference dropped to about 10–20 % or something such.

[Cageman]

I've used Surface Baking Camera to bake heightmaps. Very simple shading and I used alot of AA. My four cores were running 100% throughout the rendering.

[GraphXs]

Great, didn't really think about just turning on the render buffers, that makes sense. Maybe I never did it because I would use FPrime w/surface baking camera mainly with AO passes.

I'm spoiled by Max's "render to texture", because it allows the saving of all types of passes within the baking tool in the all in one location.

[geo_n]

I'm spoiled by Max's "render to texture", because it allows the saving of all types of passes within the baking tool in the all in one location.

I'm thinking the same

http://www.newtek.com/forums/showpost.php?p=1007298&postcount=6

Been using max render to texture to get complete maps for all selected objects in viewport and automatic shell material applied after baking.

Maybe a feature request for lwhc :D

[Captain Obvious]

you added a fogbugz for this issue?
I think I did. I filed a bunch of bug reports back then, and I think this was one of them.



Okay, ran some tests with the default surface baker:

With the attached simple scene, LW 9.6, Intel quadcore...

30 AA samples, simple shading (no ray tracing):
1 thread: 107 seconds
4 threads: 97 seconds
speed increase: 10 %
CPU utilization: <30 %


1 AA sample, complex shading (ambient occlusion, 100 samples):
1 thread: 285 seconds
4 threads: 97 seconds
speed increase: 294 %
CPU utilization: 87 %



30 AA samples, simple shading, PERSPECTIVE CAMERA:
1 thread: 44 seconds
4 threads: 13 seconds
speed increase: 338 %
CPU utilization: 100 %

[Captain Obvious]

I'm spoiled by Max's "render to texture", because it allows the saving of all types of passes within the baking tool in the all in one location.
Maybe so, but one of the advantages of Lightwave's approach is that's a full render, and you can even bake things that are motion blurred and whatnot.

[Sensei]

I tried your scene with TrueArt's Batch Baking Camera, and here are the results:

78 seconds with Surface Baking Camera
http://www.trueart.eu/Products/Plug-Ins/BatchBakingCamera/Graphics/BakeMe_1.JPG

40 seconds with Batch Baking Camera
http://www.trueart.eu/Products/Plug-Ins/BatchBakingCamera/Graphics/BakeMe_2.JPG

I didn't change any settings, so it's 30 AA Passes, 1024x512.

That's the first object I saw ever, which needs turning on Extensive Scanning to list UV Maps.. How do you archived that? ;)

[Captain Obvious]

I didn't change any settings, so it's 30 AA Passes, 1024x512.
Could you try it with one thread and with multiple threads as well, so we can see the difference in CPU utilization? And then try the same with node shading turned on. Otherwise, it's not really a relevant comparison. I see in the images it was set to eight threads. If you were rendering on with eight cores, you should see a greater performance increase with your baker over the surface baking camera than a mere 100 %.


That's the first object I saw ever, which needs turning on Extensive Scanning to list UV Maps.. How do you archived that?
It's just two unit toroids from out of modo... I didn't really do anything special to it.

[Sensei]

New version v1.1 with Windows 64 bit support and speed-up 40-80% is available.

Benchmark made on Core i7 930 2.8 GHz, LightWave v9.6 build 1539 32 bit.

Output 512x512, 1 AA pass, UV Border 0

2600 polygons object Spherical Mapping, filling whole UV space
Batch Baking Camera 0.5 second (300% faster)
Surface Baking Camera 1.5 seconds

2600 polygons object Atlas Mapping
Batch Baking Camera 0.3 second (366% faster)
Surface Baking Camera 1.1 seconds

210,000 polygons object Spherical Mapping, filling whole UV space
Batch Baking Camera 1.4 seconds (235% faster)
Surface Baking Camera 3.8 seconds

210,000 polygons object Atlas Mapping
Batch Baking Camera 1.3 seconds (271% faster)
Surface Baking Camera 3.2 seconds



Output 1024x1024, 9 AA pass, UV Border 0

2600 polygons object Spherical Mapping, filling whole UV space
Batch Baking Camera 7.6 seconds (353% faster)
Surface Baking Camera 26.8 seconds

2600 polygons object Atlas Mapping
Batch Baking Camera 3.8 seconds (418% faster)
Surface Baking Camera 15.9 seconds

210,000 polygons object Spherical Mapping, filling whole UV space
Batch Baking Camera 10.8 seconds (323% faster)
Surface Baking Camera 34.9 seconds

210,000 polygons object Atlas Mapping
Batch Baking Camera 6.4 seconds (325% faster)
Surface Baking Camera 20.8 seconds

Captain Obvious's scene rendered in 28.9 seconds (270% faster).
Surface Baking 78 seconds.

[Captain Obvious]

Captain Obvious's scene rendered in 28.9 seconds (270% faster).
Surface Baking 78 seconds.
Was that with the AO shader turned on? Simply tick on the nodal shading for the surface. This is the key thing I'm interested in — performance with complex* shading. Nice to see a 64-bit version! :)


* AO isn't really complex shading, as such, but it is certainly heavier than just simple texturing and no GI etc.

[Sensei]

Was that with the AO shader turned on?

Of course not..

Simply tick on the nodal shading for the surface. This is the key thing I'm interested in — performance with complex* shading.

This only showed that you have problems with logic thinking.. ;)

Because it's completely not testing speed of baking process (which is essentially finding triangle to which send ray), but slowness of complex shading, where 99% of cpu time is spend on ray-tracing in Ambient Occlusion.

Obviously results will be 27 minutes for one, 28 minutes for other.. ;)
Where 26 minutes 40 seconds is spend inside of AO node..
1024 * 512 * 30 AA passes * 100 AO samples = 1.5 billion rays casted, just to prove AO without caching is slow.. ;)

Just like benchmarking Ferrari speed in New York City traffic jam..

[Captain Obvious]

where 99% of cpu time is spend on ray-tracing in Ambient Occlusion.
That's exactly my point! If you're telling people that this thing is four times faster than the built in solution, I want to see some numbers for realistic scenarios, not just the highest possible. Baking something without complex shading is pointless for what I do. If it renders quickly, I don't need to bake it!

[Cageman]

That's exactly my point! If you're telling people that this thing is four times faster than the built in solution, I want to see some numbers for realistic scenarios, not just the highest possible. Baking something without complex shading is pointless for what I do. If it renders quickly, I don't need to bake it!

What you are asking about here are new and faster shaders, not new cameratypes. TrueArts camera is faster compared to the original one, at least from the point of view that he have forwarded (simple meshtracing). It does communicate to me that the original surface baking camera might not be as optimized as it should be.

I downloaded your scenefile and it completely refuses to render with the node activated.

[Captain Obvious]

What you are asking about here are new and faster shaders, not new cameratypes.
No, what I'm asking for is a realistic baking scenario. A single image map based texture and a non-shadowed distant light is not a realistic scenario — the last time I was in a baking workflow, I had bakes that were taking several hours at 2k by 2k. I honestly do not care if you turn a 20 second bake into a 5 second bake.

[Cageman]

No, what I'm asking for is a realistic baking scenario. A single image map based texture and a non-shadowed distant light is not a realistic scenario — the last time I was in a baking workflow, I had bakes that were taking several hours at 2k by 2k. I honestly do not care if you turn a 20 second bake into a 5 second bake.

Sure... but it helps to know that TruArt have done what he can on his part to make the camera as fast as possible, no?

I'm also curios to hear what the rendertimes are with that testcontent you provided, because in my case, it didn't render at all.

:)

[Captain Obvious]

Sure... but it helps to know that TruArt have done what he can on his part to make the camera as fast as possible, no?
Of, for sure. But our in-house camera was pretty fast too. :)

[Sensei]

I'm also curios to hear what the rendertimes are with that testcontent you provided, because in my case, it didn't render at all.


On Core i7 930 2.8 GHz, it's 30+ minutes.. ;)

Somebody who is baking occasionally, just to speed up some part of scene, apparently like Captain Obvious, rather will not be interested in investment in this tool.

The target is game maker (actually we're in *Game Development* section): person who has f.e. 20+ characters in high res, to bake to low res objects. Quality of object should be as best as possible, which means converting any geometrical details with procedural bump maps into normal maps. Procedural textures, nodes and anything 3d application related resource converts to image map on disk, that will be possible to load by game engine. In 99% of it, there is no *complex shading*.

With Batch Baking Camera it's as easy as loading all characters to Layout, change camera type, adjust first and last frames in Render Globals, and press F10 and watch tv or play game..

With Surface Baking Camera game maker would have to constantly changing item and uv in drop-down lists in GUI, pressing F9, and saving it manually on disk. Constant activity.

[Cageman]

Of, for sure. But our in-house camera was pretty fast too. :)

Well... not all of us have access to your inhouse toolsets/scripts or plugins though. I think it is good that TrueArt have developed this camera to automate things enmasse.

Especially regarding the fact that we are in the Game Development section of the forum.

:)

[roctavian]

OOOOh man, it`s soooo obvious.

[Captain Obvious]

Somebody who is baking occasionally, just to speed up some part of scene, apparently like Captain Obvious, rather will not be interested in investment in this tool.
Oh, I wouldn't be so sure about that! When I do need to bake, it's usually quite a few UV maps and setting it up manually is a PITA. So I might actually end up buying your baker anyway. :)

[Sensei]

I have made TrueArt's BatchBakingCamera plug-in video. It's showing baking high res details to low res object (300k to 18k). Every frame has it's own UV map (so object has >70 UV maps). They are automatically assigned to frames in animation. So to render some specific UV map, you have to set frame slider in right position. Of course loading and rendering scene to render network will also work, how it would work you can imagine basing on this video:
http://www2.trueart.pl/Products/Plug-Ins/BatchBakingCamera/Graphics/Movies/BatchBakingCamera_1.mov
(please download and watch in off-line player).
As you can see in this video BatchBakingCamera is approximately 250% faster than LW SurfaceBakingCamera without using UV Border. With UV Border it dramatically increases logarithmically, and with 10px used in video, it's almost 400% faster.

[Cageman]

As you can see in this video BatchBakingCamera is approximately 250% faster than LW SurfaceBakingCamera without using UV Border. With UV Border it dramatically increases logarithmically, and with 10px used in video, it's almost 400% faster.

Hehe... yes... the speed is quite damn amazing! :) Thanks for the video, this has put your plugin on my list of tools to buy!

:)

[roctavian]

I purchased Sensei`s Batch Baking Camera .
Indeed it renders faster, which is nice.
Unfortunately, I found the same padding issues the lw default baking camera have: discontinuous pixel border.
I`attached the content Sensei used to do his demo movie (I sent him the files when I noticed a bug). In the movie all the rendered bakes are fine.
This padding issue is not a constant behavior. It occurs randomly and only on UV island where the geometry is a continuous mesh.
I told Sensei about this issues but his answer was that he was lucky. :)
Unfortunately, I was not that lucky. :bangwall:
I`m posting the scene here for testing, maybe some of you, who purchased the plugin, can confirm this. In the image below is frame 1.
Thanks.

[erikals]

triple the object?

[roctavian]

nope. no tricks found here.
Surface baking camera is doing the same.
maybe lightwave is the problem. :)

[walfridson]

hm we had a same kind of problem...
problem was floating point inaccuracy in lw or something, when a ray hits close to an edge.

[Cageman]

hm we had a same kind of problem...
problem was floating point inaccuracy in lw or something, when a ray hits close to an edge.

What about changing Ray Precision in Render Globals?

From the manual:

"Ray Precision

This floating point value will allow users to adjust the intersection precision of the ray tracer. The default is 6 which means 1.0E-6. The higher the number, the higher the precision. If the user sets the value to 0, ray trace precision is disabled entirely. This actually works fine in most scenes."

[adk]

I also got this plug roctavian, so at least I can tell you that you're not alone in seeing this edge padding bug. I've mentioned this to Sensei as well and am waiting for his reply as I'm not sure if it's a LW issue or something in the plug that can be fixed.

Here's a gif from that scene that you asked me to test out & yeah it exhibits the same issue you have. I changed the BG to a more obvious colour (no radiosity) & rendered it with various Ray precision settings as well as Quickshade & they all show the same issue. When you move the high poly mesh down slightly, by 10 mm increments, the bottom edge improves but after a while the issue pops up on the top edge & there seems no way to get it 100%. Weird ?

From my somewhat technically challenged view...
If the plug simply "smeared out" the edge pixels to achieve the padding then I think it would work but in this case I think it's raytracing the padded edge area and the problem arises when some of those rays only see the BG.

This is with LW 9.6 x32.

[roctavian]

Thanks for testing it.:thumbsup:
I think it`s a lightwave issue, so lets hope this will be fixed in the next lightwave version.

[walfridson]

Would be nice to see this tested in the HC section hrm.. :)

[roctavian]

Would be nice to see this tested in the HC section hrm.. :)

Johan, I was thinking more about 9.6.1. :)
I don`t see a reason why this fix should be posponed for LW10.

[walfridson]

ok OB section then :D

[adk]

Thanks for testing it.:thumbsup:
I think it`s a lightwave issue, so lets hope this will be fixed in the next lightwave version.

No probs ... but I'm still not convinced (until told otherwise) that it's purely a LW issue ? On the video Sensei posted all the padding looks clean & without errors. You mentioned that he said he got lucky but as yet none of us can get those lucky clean results & still no word as to when this will be fixed (from either parties). Which in the end for me means ... I can't use either to do the stuff I need :(

[walfridson]

This is really stupid thing but work in some cases, until Sensei comes up with a fix some might find it usefull.
http://hem.spray.se/johan.walfridson/EdgeExpand.zip
It's a image filter plugin, don't use it on images - only as render processing image filter.
It will look for alpha edge and expand the rendered pixels.
32 and 64bit

[erikals]

ey, great! :]

http://erikalstad.com/backup/anims.php_files/023.gif

[adk]

This is really stupid thing but work in some cases, until Sensei comes up with a fix some might find it usefull.
http://hem.spray.se/johan.walfridson/EdgeExpand.zip
It's a image filter plugin, don't use it on images - only as render processing image filter.
It will look for alpha edge and expand the rendered pixels.
32 and 64bit

It's bloody great :thumbsup: that's what it is, as it has just fixed my issue . Cheers a bunch Johan

Not sure of the pros & cons of either approach (I'm sure there's a technical reason why it's been done via raytracing till now) but to me it actually seems a smarter way of doing edge padding. Cause it works as expected :D

[roctavian]

This is really stupid thing but work in some cases, until Sensei comes up with a fix some might find it usefull.
http://hem.spray.se/johan.walfridson/EdgeExpand.zip
It's a image filter plugin, don't use it on images - only as render processing image filter.
It will look for alpha edge and expand the rendered pixels.
32 and 64bit

It is a little bit different than the normal edge border because of the 45 degres rotated pattern.
Is possible to work for the first mipmap, but I`m not sure about the rest of the mipmaps. I gues that`s why you said is working in some cases. If no mipmaps are used maybe is good enought.
I suppose the "normal" edge border it`s done in 3d because this is the only way to detect the angle orientation of the edge to do a perpendicular on the edge pixel expanding.
I still hope a correct fix from Newtek.
However, Johan thank you very much for your effort.
I really appreciate it.:thumbsup:

[roctavian]

With Batch Baking Camera it's as easy as loading all characters to Layout, change camera type, adjust first and last frames in Render Globals, and press F10 and watch tv or play game..

It will be nice to be that simple.

Therefore it allows using Render Scene command (F10 key), or sending whole scene to renderfarm and render hundred or thousands object surfaces in one single key press.


Instead of rendering a frame range and trying to avoid baking of unneeded UVs, for the Range Type I`m using Arbitrary mode. But there is a problem here to. The frames field doesn`t accept more than 170 characters. That means a limited number of frames.
I fogged this bug (case 32839) and for better understanding, this is the bug report:

This bug is a 100% reproducible bug with Lightwave 9.6 and 2015 HC build.
The bug consist of: a limited string of numbers to input in the Render Globals panel/General tab/Range type - Arbitrary/Frames input field

To reproduce the bug please follow the steps:
1. Open Layout
2. Open Render Globals window/General tab
3. Range Type option, switch from Single to Arbitrary

4. Replace the 1-60 default values with this string of frames: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70

5. Hit Enter and try to save the scene. It will crash and write to disk an invalid .lws file.

My guess is that the Frames field doesn`t accept more than 170 characters, or a relative similar number. Sometime, during my work I need to render a huge number of frames in Arbitrary mode. The string I needed to place was huge, something like 700-800 characters. It will be nice the limit to be a lot bigger, something like 5-10,000 characters, or even unlimited.
If I added a string from 1 to 60 it was fine. The moment I added frame 61 to the string it crashed.
I edited a scene file in notepad and added a string from 1 to 70 frames.
When i opened the .lws file, Layout didn`t read from frame 61 to 70, even though the frames were saved in the file. Please find the modified scene file in the attachment.
Thank you.

[Sensei]

Instead of rendering a frame range and trying to avoid baking of unneeded UVs, for the Range Type I`m using Arbitrary mode.

I would rather open object in Modeler, and delete unneeded uvs and save in temporary file (or F10 without saving)..

If uvs are named ordinary like all the rest, then you have to check everything in Modeler UV viewport anyway, otherwise in Layout you would be confused in seconds when working with 50+ uvs like you do.. If they have (or have not) some special prefix/suffix then it's even easier to get ride of them in Modeler's Vertex Maps window..


But there is a problem here to. The frames field doesn`t accept more than 170 characters. That means a limited number of frames.

Thanks for finding bug and sharing. That's probably existing since ever. Static buffer for string in Layout. Fixing by using other static length like 1024+ would be a few seconds for NewTek programmers..