One TGO = good. Population = Bad

Started by neon22, September 02, 2007, 12:19:48 am

Previous topic - Next topic

Buzzzzz

Quote from: jo on September 02, 2007, 10:41:35 pm
Hi Lucio,

Quote from: Lucio on September 02, 2007, 07:03:46 pmA lot of time has passed, and I'm still using the first public release, version 1.8.64.0. It's a little frustrating.


Why are you still using that version exactly? Things have moved on a lot since then, a lot of problems have been fixed, particularly regarding object support.

Regards,

Jo


In the Wrong direction maybe?


Buzzzzz

I'd like to hear from the Testers on this one.  So why did we have to wait so long for this let down?

bigben

This was a bit worrying so I tried it out. My first render was OK so I tried various things to try and reproduce the problem... another productive train journey  ;)

Load population, smooth normals on by default, renders OK.
Turn off smooth normals, renders OK
Turn on smooth normals, render is black
Turn off smooth normals, render remains black.
Exit and load with smooth normals off, renders OK.
Turn smooth normals on, render is black
Save with smooth normals on, restart TG2 and reload, renders OK
Repeated with the same results.

I was only using a small population (100x100m, 30m spacing). Test objectwas the XFrog sequoia.  This doesn't really provide a definintive answer on how to get it to work but it may provide some clues.

While on objects. One thing that I've found with most imported models is that many textures need to be tiled to be scaled correctly (tree bark textures and bump maps in particular). Rather than use a colour image in the default shader I add the texture as an image map specifying the size and repetition and plug this into the colour function of the default shader.

bigben

September 03, 2007, 07:00:48 pm #18 Last Edit: September 03, 2007, 07:10:30 pm by bigben
Ohhh. one other thing, I fogot to mention.  The reason I turned smooth normals off in the first place was that I had previously set a displacement of  0.05 in the bark using a bump map. The displacement on the outer branches was pretty wild considering the small values, but turning smooth normals off made no difference. As I hadn't actually seen the top of the tree with that displacement prior to the update I couldn't state for certain that it was related to the update.

Hang on.... In my previous test you can just see the leaves, which look OK. Rendering the bottom of the trunks now and they're displaying similar problems (displacement off, smooth normals). Partial renders with smooth normals on and off below.

Lucio

Well, it seems something serious, a real killer. I just want to emphasize that this is a new problem, an issue never seen before in previous releases. This puzzles me a little. As Harvey said, I hope in a quick fix from Planetside Team.

JohnnyBoy

Ok, I tried objects exported from XSI and have the same problem. I tried checking quality level, smoothing, double sided, but I still get this rendering issue.

Buzzzzz

@ Big Ben, I appreciate your effort to create a workaround if that's what you are doing? I would suggest using spheres in your tests as trees tend to hide errors. I don't think every time we get an update that we should have to create a work around to fix what doesn't work.  Especially this close to the final release.

bigben

No, I was more trying to find a trigger for it as my first renders looked OK, but it turns out that that was only because I couldn't see the trunks.  The fact that toggling the smooth normal settings (which also reloads the object) can lead to surfaces rendering completely black may be an extra clue for seeing where the problem is.  We can't do anything to fix the problem by programming, but the more info we can provide the developers on a problem the easier it may be to track down.. and the quicker a fix is released.

Buzzzzz

Quote from: bigben on September 03, 2007, 09:18:00 pm
No, I was more trying to find a trigger for it as my first renders looked OK, but it turns out that that was only because I couldn't see the trunks.  The fact that toggling the smooth normal settings (which also reloads the object) can lead to surfaces rendering completely black may be an extra clue for seeing where the problem is.  We can't do anything to fix the problem by programming, but the more info we can provide the developers on a problem the easier it may be to track down.. and the quicker a fix is released.


Very True.  :)

Mr_Lamppost

I have experienced exactly the same problem.  I even made a couple of tests with a single object and population both with and without smoothing.  I used a mushroom object that I had made a while ago using Wings 3D, it is fairly simple and illustrates the problem well.  I know it is a little redundant but here are the results any how:
Smoke me a kipper I'll be back for breakfast.

bigben

September 03, 2007, 10:06:14 pm #25 Last Edit: September 03, 2007, 10:08:50 pm by bigben
There is a significant difference between the CLI and the GUI versions, although there are still significant differences between the single object and population.

This render is using the CLI. Single object on left, other two are in the population, (same as my previous sample). Both have smooth normals on.

Mr_Lamppost

There was already a problem with populations rendering incorrectly:

http://forums.planetside.co.uk/index.php?topic=1813.0

This was far less noticeable than the new problem with normals.

I had seen this a few times, it appears that an odd vertex was being displaced along its normal by a large amount; related problem?

The lines did respond to an increase in render quality and choosing highest quality for population objects but no such luck with this new manifestation. 

Smoke me a kipper I'll be back for breakfast.

cyphyr

I made a test using the Sweet Birch from the Xfrog free samples and also found it satisfactory. I could tell a very slight difference between the single and populated objects when rendered together but so little to be irrelevant. I did wonder if there was a correlation between the package used to create the obj in the first place. It might be useful to try the ball test with a variety of different modelers and compare the results. My results came from Lightwave exported as obj and re-exported via polytrans.

Richard
www.richardfraser.co.uk
https://www.facebook.com/RichardFraserVFX/
/|\

Ryzen 9 3900X @3.79Ghz, 64Gb (TG4 benchmark 6:20)
i7 5930K @3.5Ghz, 32Gb (TG4 benchmark 13.44)

bigben

Richard: Leaves are fine, you want to check a close up of the trunk.

Harvey Birdman

I don't know, Ben and Richard, I think the difference IS obvious in the birch leaves in Richard's pic. It might not jump right out and bite you like it does on the larger, more obvious surfaces, but the lighting is still incorrect.

I think Buzzzzz is right - the thing to do is concentrate on simpler objects like spheres and cubes that show the problem unequivocally. A fix will be equally obvious on these objects, as opposed to complex objects that have complex lighting/shadow patterns that obscure the trouble.