interesting find regarding geometry exporting

Discussions about general topics of interest, like lighting, material customization and so one
Rivaliant
Posts: 45
Joined: Mon Oct 09, 2017 6:43 am

Re: interesting find regarding geometry exporting

Postby Rivaliant » Sat Apr 21, 2018 3:06 am

about an hour of prodding i can't get the scene to use the textures at all

running the old scene file out the box works, but it Doesn't load textures at all

and finally getting that code patch to work only seems to resave the scene And THEN still fails to use the textures when loaded into LuxCore
I keep spitting out an error for the "Filesaver.directory" when saved to anything other then my H:/ drive

but there is also that error upthere with the 'kr' incorrect value, which is the Metal
with out Scene Format break down, we've hit another wall

Rivaliant
Posts: 45
Joined: Mon Oct 09, 2017 6:43 am

Re: interesting find regarding geometry exporting

Postby Rivaliant » Sat Apr 21, 2018 7:24 am

so i ran a test on that table from the first thread, i had copied over the ply files from a Realty 2 export by renaming the files and replacing the Reality 4 ply exports and the render looked incredibly clean compared to the fix i had done

I'm not sure if its just the render time i did


But i want you to think on this for one moment

I have seen rendering times plummet in relation to the number of polygons on an obj
The higher you subdivide it the more apparent calculations it has to make for the light rays to bounce from these numerous polygons

but what if these off count vertices ( remember a cube has 8, and it jumps to 18, that 2 per corner plus a random 2 in having 3)
are subjecting the calculations with random, odd, or incorrect results?

Correct me of i'm wrong but it would explain the excessive noise

i mean, imagine a plane with the four corners nailed down at its points (the vertices)
and you bounce a bunch of balls on it in rapid succession, they are going to have a predictable pattern

But then what if you take out on of the nails
now the plane has some give to it, you're going to get a ball that bounces Into the plane before it bounces off, making it bounce in a totally diffrent direction then the rest of the balls
I know that doesn't make too much sense in 3d, but what if you get a light ray that strikes a surface where there Should be a solid count of vercities but there isn't

Like the cube, near the corner that only has two rather then the three
Wouldn't its bounce be considerably diffrent?

correct me if i'm thinking about this wrong

Rivaliant
Posts: 45
Joined: Mon Oct 09, 2017 6:43 am

Re: interesting find regarding geometry exporting

Postby Rivaliant » Sun Apr 22, 2018 9:10 am

Ok no seriously check this out

I exported the cube as Text/ Lux native

which it writes out coordinates in the .LXI in Reality 4
and the .LXO file in Reality 2


remember i said i found that in MeshLab that the vertice count from Reality 4 was off, missing vertices

well exporting the coordinates acutally reveals which ones are missing
and this is kind fascinating
This is the Reality 2 object text code for that one Cube

Code: Select all

# -- Scene generated with Reality 2.50.1.122 (http://www.preta3d.com)--
# Object cube
AttributeBegin
NamedMaterial "Default_2"
Shape "mesh" # 24 vertices
"point P" [
-0.762000 -0.762000 0.000000
0.762000 -0.762000 0.000000
0.762000 -0.762000 1.524000
-0.762000 -0.762000 1.524000
0.762000 0.762000 0.000000
-0.762000 0.762000 0.000000
-0.762000 0.762000 1.524000
0.762000 0.762000 1.524000
-0.762000 0.762000 0.000000
-0.762000 -0.762000 0.000000
-0.762000 -0.762000 1.524000
-0.762000 0.762000 1.524000
0.762000 -0.762000 0.000000
0.762000 0.762000 0.000000
0.762000 0.762000 1.524000
0.762000 -0.762000 1.524000
-0.762000 -0.762000 1.524000
0.762000 -0.762000 1.524000
0.762000 0.762000 1.524000
-0.762000 0.762000 1.524000
-0.762000 0.762000 0.000000
0.762000 0.762000 0.000000
0.762000 -0.762000 0.000000
-0.762000 -0.762000 0.000000
]
"integer triindices" [
0 1 2
0 2 3
4 5 6
4 6 7
8 9 10
8 10 11
12 13 14
12 14 15
16 17 18
16 18 19
20 21 22
20 22 23
]
"normal N" [
0.000000 -0.998308 0.000000
0.000000 -0.998308 0.000000
0.000000 -0.998308 0.000000
0.000000 -0.998308 0.000000
0.000000 0.998308 0.000000
0.000000 0.998308 0.000000
0.000000 0.998308 0.000000
0.000000 0.998308 0.000000
-0.998308 0.000000 0.000000
-0.998308 0.000000 0.000000
-0.998308 0.000000 0.000000
-0.998308 0.000000 0.000000
0.998308 0.000000 0.000000
0.998308 0.000000 0.000000
0.998308 0.000000 0.000000
0.998308 0.000000 0.000000
0.000000 0.000000 0.998308
0.000000 0.000000 0.998308
0.000000 0.000000 0.998308
0.000000 0.000000 0.998308
0.000000 0.000000 -0.998308
0.000000 0.000000 -0.998308
0.000000 0.000000 -0.998308
0.000000 0.000000 -0.998308
]
# 24 uv entries
"float uv" [
0.000000 0.000000
0.330000 0.000000
0.330000 -0.500000
0.000000 -0.500000
0.660000 0.000000
0.990000 0.000000
0.990000 -0.500000
0.660000 -0.500000
0.660000 -0.500000
0.990000 -0.500000
0.990000 -1.000000
0.660000 -1.000000
0.330000 0.000000
0.660000 0.000000
0.660000 -0.500000
0.330000 -0.500000
0.000000 -0.500000
0.330000 -0.500000
0.330000 -1.000000
0.000000 -1.000000
0.330000 -0.500000
0.660000 -0.500000
0.660000 -1.000000
0.330000 -1.000000
]
AttributeEnd


and here is Reality 4

Code: Select all

#
# LuxRender include file. Generated by Reality plugin
#
# Mat Default (Glossy). 12 polys
AttributeBegin
NamedMaterial "cube_8-28597:Default"
Shape "mesh" "string name" ["cube_8-28597"]
"integer triindices" [
0 1 2
0 2 3
4 5 6
4 6 7
8 9 10
8 10 11
1 4 7
1 7 2
3 2 12
3 12 13
14 15 16
14 16 17
]
"point P" [
-0.762000 -0.762000 0.000000
0.762000 -0.762000 0.000000
0.762000 -0.762000 1.524000
-0.762000 -0.762000 1.524000
0.762000 0.762000 0.000000
-0.762000 0.762000 0.000000
-0.762000 0.762000 1.524000
0.762000 0.762000 1.524000
-0.762000 0.762000 0.000000
-0.762000 -0.762000 0.000000
-0.762000 -0.762000 1.524000
-0.762000 0.762000 1.524000
0.762000 0.762000 1.524000
-0.762000 0.762000 1.524000
-0.762000 0.762000 0.000000
0.762000 0.762000 0.000000
0.762000 -0.762000 0.000000
-0.762000 -0.762000 0.000000
]
"normal N" [
0.000000 -0.998308 0.000000
0.000000 -0.998308 0.000000
0.000000 -0.998308 0.000000
0.000000 -0.998308 0.000000
0.000000 0.998308 0.000000
0.000000 0.998308 0.000000
0.000000 0.998308 0.000000
0.000000 0.998308 0.000000
-0.998308 0.000000 0.000000
-0.998308 0.000000 0.000000
-0.998308 0.000000 0.000000
-0.998308 0.000000 0.000000
0.000000 0.000000 0.998308
0.000000 0.000000 0.998308
0.000000 0.000000 -0.998308
0.000000 0.000000 -0.998308
0.000000 0.000000 -0.998308
0.000000 0.000000 -0.998308
]
"float uv" [
0.00000000 0.00000000
0.33000001 0.00000000
0.33000001 0.50000000
0.00000000 0.50000000
0.66000003 0.00000000
0.99000001 0.00000000
0.99000001 0.50000000
0.66000003 0.50000000
0.66000003 0.50000000
0.99000001 0.50000000
0.99000001 1.00000000
0.66000003 1.00000000
0.33000001 1.00000000
0.00000000 1.00000000
0.33000001 0.50000000
0.66000003 0.50000000
0.66000003 1.00000000
0.33000001 1.00000000
]
AttributeEnd
# End of include file



if you dicet what the Point P segment reads out
Those are the vertices to the cube
making a 3d grid on paper, i worked out the numbers in expressions of X left or right, Y up or down, and Z forward and back
positive right up and back, negative left down and forward ( i don't know why, i'm sure this is wrong so bare with me)

and i ended up mapping out Reality 4's vertices for the cube and it happened to work out like this

Image

you have 3 corners with 3 vertices, 4 corners with 2 vertices and 1 corner with one

If you were to do the same with the point coordinates you'll end up with 3 vertices for each corner

now the actual placement by the line might be incorrect but I don't think that's whats causing the weird two toned face

if you look under the Normal N segment of the code and look between them

You'll notice a pattern
In Reality 2 you see there are 4 lines for each cardinal direction
4 Y negative
4 Y positive
4 X negative
4 X positive
4 Z postive
4 Z negative

But in Reality 4?
4 Y negative
4 Y positive
4 X negative
0 X poisitve
2 Z positive
4 Z negative

I remember Paolo making a comment in response to me pointing this out, that the there was something wrong with the normals of objs we where showing him that this was occurring


Yes, Because Reality 4 wasn't exporting the Normals on entire faces.

I'm not sure how the .ply files are coded with this information
but looking at the Text form of it

This HAS to be proof of some kind
maybe the vertice thing isn't that big of a problem

But these missing normal lines, have to be the reason for the black segments of the cube that are predictably showing up.

Please someone recreate this so we can figure out what is the difference if we find that someoen Isn't having this issue so I can work to resolve it so i can get my rendering quality back

create a cube that is 5 feet in size with 1 division
set the ibl on and se the Geometry format to Lux Text and Render

Open the LXI file as a WordPad

User avatar
sigstan
Posts: 437
Joined: Sat Jan 24, 2015 3:59 pm
Location: Denmark

Re: interesting find regarding geometry exporting

Postby sigstan » Sun Apr 22, 2018 2:59 pm

Well, this is interesting.

It should be a pretty straight forward geometry issue. A cube has 6 Faces, 8 Vertices, and 12 Edges. This is the minimal configuration, but assumes all faces are the exact same.

If you want to vary the faces, for example put a different texture on each face, then you need more than 8 vertices, because UVs and normals cannot share vertices without causing issues. This means we need 4 vertices per face, so 6 * 4 = 24 vertices. Technically the faces will be divided in triangles, so that means 6 * 2 = 12 triangles.

Exporting a non-subdivided cube I expect to see 24 vertices ("point P"), 12 indices for the triangles ("integer triindices"), 24 normals and 24 UVs.

Now looking at the file created by Reality 2, this is exactly what is being exported:
24 vertices, 12 indices, 24 normals and 24 UVs.

However, in the Reality 4 file, we have:
18 vertices, 12 indices, 18 normals and 18 UVs.

That does not add up, and has to be a a bug.

Now we could be dealing with some kind of DS primitive issue here, but if you can confirm that you are running the export for both Reality 2 and Reality 4 in the same version of DS, then we can probably rule out the problem being in DS. otherwise we need to take a deeper dive into the problem.
/Sigstan

Rivaliant
Posts: 45
Joined: Mon Oct 09, 2017 6:43 am

Re: interesting find regarding geometry exporting

Postby Rivaliant » Mon Apr 23, 2018 4:18 am

sigstan wrote:Well, this is interesting.

It should be a pretty straight forward geometry issue. A cube has 6 Faces, 8 Vertices, and 12 Edges. This is the minimal configuration, but assumes all faces are the exact same.

If you want to vary the faces, for example put a different texture on each face, then you need more than 8 vertices, because UVs and normals cannot share vertices without causing issues. This means we need 4 vertices per face, so 6 * 4 = 24 vertices. Technically the faces will be divided in triangles, so that means 6 * 2 = 12 triangles.

Exporting a non-subdivided cube I expect to see 24 vertices ("point P"), 12 indices for the triangles ("integer triindices"), 24 normals and 24 UVs.

Now looking at the file created by Reality 2, this is exactly what is being exported:
24 vertices, 12 indices, 24 normals and 24 UVs.

However, in the Reality 4 file, we have:
18 vertices, 12 indices, 18 normals and 18 UVs.

That does not add up, and has to be a a bug.

Now we could be dealing with some kind of DS primitive issue here, but if you can confirm that you are running the export for both Reality 2 and Reality 4 in the same version of DS, then we can probably rule out the problem being in DS. otherwise we need to take a deeper dive into the problem.

if you can confirm that you are running the export for both Reality 2 and Reality 4 in the same version of DS


I can in fact confirm that they are coming from Reality though Daz Studio 4.8.0.59 Pro Edition 64bit (never upgraded because i heard some bad things about the later version of Daz Studio)

if you need some kind visual proof, i can even video record it if you need me to lol

if its just a matter of the version of Daz Studio i'm using, then i'd like to know so I can just upgrade it after all
but i'd also like to know if this is an issue across the board with even the latest version of Daz Studio
and if those that Don't ahve this issue, what other differences can we narrow it down to

User avatar
sigstan
Posts: 437
Joined: Sat Jan 24, 2015 3:59 pm
Location: Denmark

Re: interesting find regarding geometry exporting

Postby sigstan » Mon Apr 23, 2018 5:06 pm

I'm using DAZ Studio 4.10.0.107 64bit and that still has the issue, so I do not think it has anything to do with the version of DS.

But we have a situation where Reality 4 is not exporting the DS cube primitive correctly and given that Reality 2 apparently can export the same cube primitive correctly in the same DS version, it looks like Reality 4 has an export bug.

Paolo, what is your take on this one?
/Sigstan

Rivaliant
Posts: 45
Joined: Mon Oct 09, 2017 6:43 am

Re: interesting find regarding geometry exporting

Postby Rivaliant » Mon Apr 23, 2018 7:17 pm

sigstan wrote:I'm using DAZ Studio 4.10.0.107 64bit and that still has the issue, so I do not think it has anything to do with the version of DS.

But we have a situation where Reality 4 is not exporting the DS cube primitive correctly and given that Reality 2 apparently can export the same cube primitive correctly in the same DS version, it looks like Reality 4 has an export bug.

Paolo, what is your take on this one?


I just got confirmation from another Daz/Reality 4 user experiences the same thing

the Thing is i don't Think it's just the cube primitive
I think its most, if not all, planar geometry (totally flat surfaces)

Image Image
Image Image

forcing these surfaces to use Micro-facets displacement without actual displacement ( so just micro sub-division )
alleviates the problem
But the solution is forcing more points to give more Normals to face in the correct directions aor out right give a direction for what is "up" and pushing the missing vertices and missing normals into a very small area(assuming)


Return to “General”

Who is online

Users browsing this forum: No registered users and 3 guests