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

## interesting find regarding geometry exporting

### Re: interesting find regarding geometry exporting

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

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

### Re: interesting find regarding geometry exporting

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.

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

### Re: interesting find regarding geometry exporting

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?

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

### Who is online

Users browsing this forum: No registered users and 2 guests