PDA

View Full Version : Getting Vertex Normal Maps to render properly?



WShawn
10-19-2009, 05:36 PM
Hi:

Is there some Node Editor mojo I can use to get a surface using a Vertex Normal Map to render properly? Sensei seems to imply that you can use vector math on the Normals node to do this in this thread,

http://www.newtek.com/forums/showthread.php?t=60529&page=6

but it's not a detailed explanation and I don't understand the whole process. Node editing isn't my strength.

We just invested $900 for Polytrans and its CAD modules so we can import various CAD formats into Lightwave.

The client's provided a STEP file for us to work with. Polytrans seems to do a decent job transforming the STEP file to 400+ Lightwave objects in a scene. There's only one surface and it has the Vertex Normal Map set to vert_normals. Unfortunately, the normals appear flipped (or something). If I put a light right in front of the object the Open GL display looks like the light is coming from behind the object. Renders look dark and wrong using the Perspective Camera. They look really really dark with the Classic camera. Strangely, the render looks pretty good in FPrime. There are a few smoothing issues here and there, but at least the light looks like it's coming from the right direction.

Any thoughts or suggestions would be greatly appreciated.

Thanks.

Shawn Marshall
Marshall Arts Motion Graphics

LW 9.6, Mac OS 10.5.5

Sensei
10-20-2009, 12:17 AM
Fprime is/was never reading normal vectors from LWSDK- actually it's slowing down mesh scanning 300%.. So, whatever Fprime shows you is as good as manually imported object without normal vectors - try pressing Smooth in Surface Editor and you should see flat faces..

bjornkn
10-20-2009, 01:33 AM
I thought vertex normal maps was only available when importing OBJ files that contained them?
I also import STEP files into PolyTrans/NuGraf, but as I export as LWO I never get any vertex maps AFAIK?

StereoMike
10-20-2009, 02:25 AM
I would as well like to know how I can get the vertex normal maps from solids converted to lwo (with polytrans). Right now I go rather hi poly to obtain smooth surfaces, if I knew how to get vertex normals to use in lw, I could reduce polycount and thus render quicker...

WShawn
10-20-2009, 02:33 AM
Sensei:

Thanks for the reply. You are correct; FPrime is just ignoring the Vertex Normal Map. I didn't want to render this in FPrime anyway. I'd mainly like to know if you (or someone) had any suggestions as to how I could use Nodes to make the Normals appear correct on render.

If that's not possible I'd like to just turn off the Vertex Normal Map, but I can't find a way to do that globally for all of the 429 objects that make up this product. As far as I can tell I have to select each object's surface one at a time and set the Vertex Normal Map to "none." I tried editing the surface by scene (all of the parts share the same surface name) but it doesn't work. Even if I paste a surface with the map set to "none" to one that has it set to "vert_normals," everything changes except that "vert_normals" setting. I have to change that by hand. 429 times. Brilliant.

Is there any way to make the LW renderer ignore Vertex Normal Maps like the FPrime renderer?

Thanks.

Shawn Marshall
Marshall Arts Motion Graphics

Sensei
10-20-2009, 03:13 AM
Thanks for the reply. You are correct; FPrime is just ignoring the Vertex Normal Map. I didn't want to render this in FPrime anyway. I'd mainly like to know if you (or someone) had any suggestions as to how I could use Nodes to make the Normals appear correct on render.

Use mine TrueOBJImport.. ;)
In TrueOBJImport you have node that has output "Normal", that you connect to Surface's Normal input, or material or shader.. Therefore it works in Fprime or other 3rd party renderer..
But there is problem- you have Mac, and this plug-in have no Macintosh version..



If that's not possible I'd like to just turn off the Vertex Normal Map, but I can't find a way to do that globally for all of the 429 objects that make up this product. As far as I can tell I have to select each object's surface one at a time and set the Vertex Normal Map to "none." I tried editing the surface by scene (all of the parts share the same surface name) but it doesn't work. Even if I paste a surface with the map set to "none" to one that has it set to "vert_normals," everything changes except that "vert_normals" setting. I have to change that by hand. 429 times. Brilliant.

Maybe load object or original OBJ in LW v9.5 or less. They didn't have Vertex Normal Map feature, so after saving (Save All Objects etc), map settings should be gone. But of course you will have general smoothing errors.

Other idea, I don't know whether it'll work, open Node Editor of 1st surface, take Spot Info > Smoothed Normal, and connect it to Surface's Normal input. Then copy that surface to the all 400+ objects. If Node Editor normal has precedence over Vertex Normal Map (which I think it has, because Node Editor is evaluated after ray hitting polygon, not in preprocessing stage), this method should work.

bjornkn
10-20-2009, 03:33 AM
Strange. My STEP/LWO files loads with surfaces with vertex normals set to None.
You could export as OBJ from PolyTrans, because then the vertex normal map seems to work OK.
The attached image shows a simple STEP file converted to LWO (left) and to OBJ (right).
The LWO version uses smoothing angle 19 and no vertex normal map.
The OBJ version has no smoothing, but uses the PolyTrans-exported vertex normal map.

lansd
10-22-2009, 11:55 PM
Those of the forum will now me as the Okino system architect, and I've provided all main CAD software to LW users since my 1994 release. To be honest, this is my first ever posting having to do with CAD into LW since that's an everyday affair for me and my users. WShawn was good to provide me this forum link so let me add additional info which WShawn hasn't had a chance to include in his posting yet:

1) First some quick history. I had asked/begged the LW Layout developer to add vertex normals starting in 1997, but it never happened. But once the LW developers moved over to Luxology, they finally added the "vert_normals" chunk to MODO's .lwo implementation. I added that into my Okino Lightwave import/export converters on July 4 2007. My 12 year dream of having explicit vertex normals in Lightwave came to fruition when LW 9.6 came out, as it finally implements the MODO extension of "vert_normals". That implementation has long been verified, especially after a Havoline Oil TV commercial I helped with which was based on the newest version of LW and its updated LWS file format.

2) Even without the use of explicit vertex normals, one really does not need them to get super-nice CAD renderings. While explicit vertex normals does away with any problems of LW's limited smoothing groups, the import of CAD data as "Bodies" through my CAD importers and enabling my 'Hierarchy and Object Count Optimizer' will always allow for nice CAD to LW conversions. That's the way its always been designed. I know there's those who know of my software, but for those that don't, refer to the good collection of CAD to LWS/LWO and/or Lightwave renderings from 2009 here, http://www.okino.com/mainpic13.htm (all the Cinema-4D CAD renderings were also done with Lightwave format).

3) Now, for WShawn, he is in his first '48 hours' (so to speak) of Okino program usage so I have been explaining different things to him (mostly relating on how to turn off meta data during import so that most of the useless CAD assembly nodes are removed from the tree). He has the ability now to either output explicit vertex normals ("vert_normals" maps) or use the older method of smoothing groups. My own x64 copy of LW 9.6 renders his STEP files fine, using both methods (smoothing groups and explicit vertex normals), and I've sent him back my copy of the lws/lwo files the other day to compare against his installation of LW 9.6. The data is fine, since I can re-import it and compare the vertex normals. Hence, at this point I'm just waiting to confirm with WShawn why his LW 9.6 copy isn't showing what my copy is. I've found over time that all weird 'oddities' can always be explained very simply in the end, until that explanation can be found.

ps. Just as a small clarification, the Okino software is $395 for PolyTrans (unchanged since 1996) but the license/maintenance/royalties for the PTC Pro/E Granite module with the STEP importer adds $395. That would be $790 not $900.

Sensei
10-23-2009, 12:38 AM
ps. Just as a small clarification, the Okino software is $395 for PolyTrans (unchanged since 1996) but the license/maintenance/royalties for the PTC Pro/E Granite module with the STEP importer adds $395. That would be $790 not $900.

Depending on country, there might be added VAT or similar Value Added Tax equivalent.
In my case your's $790 would become $963.8..
The lowest VAT in EU is 15%, which gives $790 * 1.15 = $908.5

lansd
10-23-2009, 12:55 AM
Depending on country, there might be added VAT or similar Value Added Tax equivalent. In my case your's $790 would become $963.8.. The lowest VAT in EU is 15%, which gives $790 * 1.15 = $908.5

This is off topic from the forum posting, but I'll add these notes:

1) The $790 is quoted in one currency, US$, the country for which WShawn resides. He should not have paid any additional taxes. It is, however, perceived by many that the US$-CDN$ exchange rate is a tax (which it is not).
2) We've been selling to Europe since about 1991 and VAT does pop up in conversations now and then, but rarely in the final sales. We sell direct from Canada to each European customer, and we don't see the VAT on our side of the sale. I recall that in Spain all purchases must be declared to the government so that VAT can be applied. The software is primarily provided by FTP download these days, so there is no customs or duties to be paid, or excise taxes.
3) In Canada there are 2 taxes, one local and one Federal, scouring 13% on most provincially purchased products (was 15% until recently). If we buy out of country (say, from USA), we can often bypass these taxes unless a broker (such as UPS) automatically adds on the Federal taxes. The most expensive part of ordering a physical product from USA is the shipping + brokerage charges by UPS, and hence why I always use FedEx.

lansd
10-23-2009, 01:03 AM
(duplicate removed)

Matt
10-23-2009, 02:40 AM
I've also had issues with LightWave and Vertex Normal Maps, I was over-joyed when they were added, but it seems they still need some work.

lansd
10-26-2009, 05:20 PM
I've also had issues with LightWave and Vertex Normal Maps, I was over-joyed when they were added, but it seems they still need some work.

I'm always very pro-active in my conversion work and I'm intrigued to get to the bottom of this oddity. To me, I have never heard of any problems with the vert_normals chunk until last Friday. I myself can't replicate these problems, otherwise I I would have seen them over the last 2.5 years. Does anyone wish to post an example so that I can compare it with my LW 9.6 installation? I've sent my STEP->LW customer my own conversions which render fine in my LW 9.6 installation. I'm not sure if there have been sub-releases of LW 9.6 - the dates on my files are from Jan 15 2009.

Sensei
10-27-2009, 12:09 AM
I'm always very pro-active in my conversion work and I'm intrigued to get to the bottom of this oddity. To me, I have never heard of any problems with the vert_normals chunk until last Friday. I myself can't replicate these problems, otherwise I I would have seen them over the last 2.5 years.

Nobody could see it in the last 2.5 years. I think the first LightWave with Vertex Normal Vectors added feature was LightWave v9.6 which was released officially 19 January 2009. So, officially it's just 8-9 month old problem.

You can find more examples in this thread
http://www.newtek.com/forums/showthread.php?t=60529&page=4
at the end are threads with obj imported by LW v9.6 with vertex normal vectors.

WShawn
10-28-2009, 03:41 PM
Just to clarify the price of the Polytrans software we purchased, we bought the base version ($395) plus the CAD/Pack + Granite/Pack bundle ($510) which makes the total $905. We wanted both the CAD and Granite packs so we'd have most of the major CAD importers covered. Buying those two packs separately would have cost an additional $130.

Shawn Marshall
Marshall Arts Motion Graphics

bjornkn
10-29-2009, 03:56 AM
Which is a bargain when compared to competition like Deep Exploration CAD edition which will cost you $3000 + $600 each year for maintenance and support.
Okino/Lansdale delivers support second to none. When I had some problems a few years ago I even had custom made converter updates sent to me within a few hours, for free. This is something which I've never experienced with other companies.

Matt
10-29-2009, 09:13 AM
Just to add, and I'd have to check this, but I _think_ they rendered fine when there was only one model with a vert map.

The moment I have a few in there, odd things start happening.

lansd
11-02-2009, 03:04 AM
Well, to finally close out this thread, I got to the bottom of this issue which now all makes sense. When Luxology defined the new "vert_normals" chunk for Modo in 2006/2007, they implemented it within their software using a right handed coordinate system. I've convinced them last week that this would be incorrect since Lightwave has always been left-handed for its mesh data, and hence needs the Z component of the vertex normals negated. Future versions of Modo will migrate to this proper policy. We can't have two standards for the Lightwave file format, as that would mean files written by Modo would have inverted normals from those written by LW 9.6+.

I've spent some good quality time revising the Okino Lightwave import/export converters so that past and future users will be able to choose between (1) no explicit vertex normals (ie. smoothing groups take precedence), (2) the old Modo policy (RHCS) and the (3) the default LW 9.6 + future new Modo policy (LHCS).

The simple, bottom line is that all files flow through into LW 9.6+ fine with explicit vertex normals.