Recent Posts

Pages: 1 [2] 3 4 ... 10
11
WIP / Re: There are many ways to go to Rome.
« Last post by Patrice Terrier on April 24, 2019, 12:05:51 pm »
See the overlapping sections when creating the UV's map for the "harley_quinn" colants material.

To solve this, the crossed legs must be splitted into two distinct meshes.
Because the editor couldn't help in such a case.
12
WIP / Re: There are many ways to go to Rome.
« Last post by Patrice Terrier on April 24, 2019, 11:57:07 am »
Quote
and host the mesh's entire UV topology without overlapping regions
Yes, overlapping regions is a terrible mess when working with AO's, forcing me to split the mesh into distinct individual pieces within C4D.

I have learned this the hard way ::)

13
WIP / Re: There are many ways to go to Rome.
« Last post by Michael Lobko-Lobanovsky on April 24, 2019, 11:48:28 am »
Quote
And as far as i can imagine, tiling mode is NEVER used to create AO's texture.
That's correct, but AO is the only texture that can't be tiled because no two parts of the same mesh may have one and the same shadow pattern. Therefore, the use of AO in an .OBJ model requires that the mesh's all other textures be generated similar to AO as clamped to edge, and host the mesh's entire UV topology without overlapping regions. But it only applies to those model formats that support only one UV set per mesh. There are however many formats that support from two to an infinite number of UV sets per mesh.

Re. acknowledgment, I'm hoping to demonstrate it on my test model later today or tonight. :)
14
WIP / Re: There are many ways to go to Rome.
« Last post by Patrice Terrier on April 24, 2019, 09:14:01 am »
Michael

In the case of Harley_quinn, i have checked the UV map produced by Tor and C4D's, they are both the same except a little offset of 1 pixel on both X,Y (the pen size), that is easy to fix.

To say the truth i can't aknowledge anything without experimentation, because it sounds a little like Hebrew to me.  :-[

A model example is the only thing that could help me to figure what to do, after comparison with the UV map produced on it by C4D, that was my leading edge reference.

And as far as i can imagine, tiling mode is NEVER used to create AO's texture.
15
WIP / Re: There are many ways to go to Rome.
« Last post by Michael Lobko-Lobanovsky on April 24, 2019, 08:48:03 am »
My friend,

Do you realize and acknowledge that currently, Tor isn't able to display the correct disposition of the triangle ABC as per my earlier message? It isn't even aware that the coords of C are in fact located in Tile 1 rather than Tile 0 because all it sees is the castrated fmod'ed coords of Cprime. Therefore, it is 100% going to distort the UV map by drawing the triangle as ABCprime. How are we then to know that what we're seeing in the zoom control viewport is exactly what happens in the mesh texture mapping, and how are we to locate the correct hot spots, and where to drag the "virtual" Cprime hot spot even if in the end we're somehow able to guess that Cprime is in fact the misplaced C apex? ::)
16
WIP / Re: There are many ways to go to Rome.
« Last post by Patrice Terrier on April 24, 2019, 08:02:06 am »
My friend

As you know it, i am reworking all the models without exception before posting them on our forum, thus if one doesn't fit into our existing paradigm is doesn't figure into the collection.
Quote
And Tor should also be made ready to display not only tile 0, but also the entire cross of tiles with the UV map extending from physical tile 0 into the surrounding virtual tiles.
About Harley-quinn, the original UV map is preserved even after editing the texCoord (or the changes won't work), thus i don't think that we must spend too much time on this, as long as the editor allows us to edit the WYSIWYG part.

As you can see in the code below, i am restoring the floor part of the textCoord before updating.

            // WE UPDATE THE UV texCoord HERE
            long idx = gnm_indexBuffer[gT.wasIndex];
            // SetTexCoordinate
            rx = gtm_vertexBuffer[idx].texCoord[0] - rxCoord(idx);
            ry = gtm_vertexBuffer[idx].texCoord[1] - ryCoord(idx);

            gtm_vertexBuffer[idx].texCoord[0] = rx + float(gT.wasX / float(nW - 1));
            gtm_vertexBuffer[idx].texCoord[1] = ry + float(1.0f - float(gT.wasY / float(nH - 1)));



I made these changes to use your fast_fmodf, but i can't see any measurable speed enhancement  :-[
float rxCoord(IN long idx) {
    return gtm_vertexBuffer[idx].texCoord[0] - ((int)(gtm_vertexBuffer[idx].texCoord[0] / 1.0f)) * 1.0f;
    //return gtm_vertexBuffer[idx].texCoord[0] - floor(gtm_vertexBuffer[idx].texCoord[0]);
}

float ryCoord(IN long idx) {
   return gtm_vertexBuffer[idx].texCoord[1] - ((int)(gtm_vertexBuffer[idx].texCoord[1] / 1.0f)) * 1.0f;
    //return gtm_vertexBuffer[idx].texCoord[1] - floor(gtm_vertexBuffer[idx].texCoord[1]);
}
17
WIP / Re: There are many ways to go to Rome.
« Last post by Michael Lobko-Lobanovsky on April 24, 2019, 05:51:54 am »
I am walking one step after another, and so far UV map is my first editor's step.
OK probably I'm running too fast. My idea was to try and design a viable universal undo/redo scheme right from the start, so that each new editing feature we're adding wouldn't require reshuffling lots of earlier code to adapt to new functionality.

But no, your first editor was the lighting editor. So now you have two editors to cater for in one undo/redo stack and you're likely to have still more of them in the future. ;)

Quote
About tiled texture i have to search a model from my collection to experiment with, because so far i couldn't remember of any.
I'll try to create a simple test model+texture for you this afternoon with one set of UVs shifted to cross the border of two tiles midways (like in my previous elementary example), and yet another one, shifted entirely to, say, tile 3 or 4 absolutely out of Tor's current reach. Tor will have to cope with both UV sets and allow us to control their map bullets/hot spots in their natural environment as easily as it currently does entirely within the boundaries of tile 0. We shouldn't simply discard the whole integer part of UVs to narrow them down to tile 0, but rather extend Tor's display area to be able to draw the virtual tiles when needed, and its hot spot overlay, to draw the entire matching UV wireframe in its true UV coords.

I believe there is absolutely no other way to implement it efficiently in the zoom control viewport other than by tiling the texture cross-wise in the direction(s) where the UVs actually protrude.

Quote
To create the UV projection ...
We do not need to create projections. They have already been created for us by the people who designed the model textures and stored their projected VT values in the model files. We need only to remap those values from their relative FPU representations to the textures' true pixel widths and heights. We can now do this for tile 0 but we have to also be able to do it for the virtual widths and heights of the entire rows of tiles where the model UVs actually protrude.

And Tor should also be made ready to display not only tile 0, but also the entire cross of tiles with the UV map extending from physical tile 0 into the surrounding virtual tiles. Think of how your physical desktop window coordinates on your primary monitor are extended into the virtual desktop on your adjacent secondary monitors.
18
WIP / Re: There are many ways to go to Rome.
« Last post by Patrice Terrier on April 23, 2019, 09:41:56 pm »
Quote
This isn't sufficient. The stack should handle all data modifications that OR's editors are able to offer.
I am walking one step after another, and so far UV map is my first editor's step.

About tiled texture i have to search a model from my collection to experiment with, because so far i couldn't remember of any.

To create the UV projection, most Google suggestions were based on the use of matrix, or the use of gluProject/gluUnProject to map object coordinates to window coordinates (also based on matrix).
https://docs.microsoft.com/en-us/windows/desktop/opengl/gluproject

https://www.khronos.org/opengl/wiki/GluProject_and_gluUnProject_code

19
WIP / Re: There are many ways to go to Rome.
« Last post by Michael Lobko-Lobanovsky on April 23, 2019, 08:40:53 pm »
For undo-redo, a dynamic global vector array is what i would use, with a structure like this.

struct UNDO_REDO {
    long idx;
    float texCoord[2];
}
to save the
gtm_vertexBuffer[idx].texCoord[0]
gtm_vertexBuffer[idx].texCoord[1]

This isn't sufficient. The stack should handle all data modifications that OR's editors are able to offer. ObjReader currently has 2 editors (lighting and texture) but your UNDO_REDO handles separate UVs only. It should be augmented with a flag to indicate what type of undo/redo operation exactly the current entry actually describes, and a union that would host any structure types we might need to restore the OR states (lights, texture UVs, vertex geo coords, etc.) arbitrarily step by step or across or over a number of steps.

Also consider group selection modes whereby an arbitrary number of indices with various associated data should be stored in one step...
20
WIP / Re: There are many ways to go to Rome.
« Last post by Michael Lobko-Lobanovsky on April 23, 2019, 08:23:53 pm »
Since you refuse to describe verbally your train of thought while implementing your patch, I'll base my comments on what I could gather from the mods.

Here is the Tor.zip able to render VT texCoord that are out of the 0-1 range.
No, this Tor is only able to discard the UVs and tris that are at least partially out of the 0-1 range.

Quote
Search for rxCoord, ryCoord
These two functions are in fact your custom implementation of fast fmod(coord, 1.f) used to actually discard the UV coords that exceed the 0-1 range. If Tor doesn't entirely discard the tris in the areas that it can't draw, then it's going to draw them incorrectly. Consider the picture below. Tor can't draw the ABC tri because the C apex belongs to Tile 1 and is thus out of Tor's reach. If the entire tri isn't discarded from the drawing process, then on fmod()'ing its C apex down to C', the tri will be drawn as ABC', which is totally wrong.

This solution will help us survive for the time being. But it doesn't allow us to work with textures that are tiled (GL_REPEATed) purposefully in order to map some UVs, or triangles, or even the entire mesh across tiles 0, 1, 2, ..., etc. or arbitrarily in any of these tiles at the model designer's option.

Am I correct in my deductions?
Pages: 1 [2] 3 4 ... 10