 |
 |
|
 |
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
but let's go back to the interesting observation that jr made
Too few polygons in some places (it was a car signal light) are not nice
You're right, I thought about it.
General algorithms are no good in my opinion.
They are recursive and have unintelligent ways.
They consume memory.
They exaggerate in the points that are already rich and perhaps are deficient in
the points that need it most.
I thought of a different criterion, to be applied only on "poor" polygons.
It is not easy but not impossible to write.
I attach the scheme of my idea.
I have 3 quads (seen from above).
I select the central one B, to improve it by splitting it in two.
Above, the 3 black quads with their normals red.
In the center, their green vertex normals, computed for POVray's smooth
triangles.
Below, I've broken B into two parts, B and B1. Finding the split point as the
midpoint between its original midline and the intersection of its lateral quads.
Now I have to recalculate the new normals ...
blue and yellow.
The bad quad is gone. If it's not enough I can select another bad quad.
Here I simplified, the sides are symmetrical, but it's just to simplify the
drawing. You can always do it.
When I have two free hours to concentrate I try.
Post a reply to this message
Attachments:
Download 'clipboard01.png' (6 KB)
Preview of image 'clipboard01.png'

|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
I worked on your scripts yesterday and I have to say, Dennis looks really cool.
In the Inc file of Bike and Audi it is quite messy, but I separated and cleaned
up Bike, Audi maybe today.
The BMW also looks good, I'll get to work on it right away.
I'll post the scripts I've changed as soon as they are presentable, until then
greetings from Dennis :)
And from me, of course.
Ma
Post a reply to this message
Attachments:
Download 'test_dennis_02.png' (251 KB)
Preview of image 'test_dennis_02.png'

|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
"Maetes" <nomail@nomail> wrote:
> I worked on your scripts yesterday and I have to say, Dennis looks really cool.
>
> In the Inc file of Bike and Audi it is quite messy, but I separated and cleaned
> up Bike, Audi maybe today.
> The BMW also looks good, I'll get to work on it right away.
>
> I'll post the scripts I've changed as soon as they are presentable, until then
> greetings from Dennis :)
>
> And from me, of course.
> Ma
Nice job!
Be careful, because Dennis was wandering around the web, I just captured him,
cleaned him, colored him, meshed him, and...
imported into our PovRay world!
thanks also to the unknown author!
PS.
I wrote that I can't post my executable for transformations here. I don't want
to post exe that often (always) worry with false positives of the antivirus.
But scripts and plugins written in plain text are not a concern, so I thought
I'd make a new topic in the next few days with two plugins for SketcUp.
- Import STL
- Export POV and/or inc.
I think they could be useful.
They are made for SketchUp 8 and SketchUp Make 2017.
In SketchUp you can give truecolor colors and transparencies that will then also
be acquired by PovRay.
The latest FREE versions (8 and Make 2017) that you can find on the web.
The most recent ones are paid and I haven't tested them.
So stay online ... if you're interested
BR
G.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
"GioSeregni" <gms### [at] hotmail com> wrote:
> General algorithms are no good in my opinion.
> They are recursive and have unintelligent ways.
> They consume memory.
> They exaggerate in the points that are already rich and perhaps are deficient in
> the points that need it most.
What you could do is test the distance between points, and points that are far
apart can get refined, and points that are close together can get skipped.
However, I'd suggest making it more sophisticated than that - test the curvature
along some distance on the surface. Flat areas get skipped, and highly curved
areas get refined. Find some way to appropriately weight the curvature vs
distance metrics.
Unnecessarily subdivided flat faces could be simplified into a single quad.
Not easy work - very tedious. But well commented code and a flowchart of the
logic would help in future development.
- BE
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
"Bald Eagle" <cre### [at] netscape net> wrote:
> "GioSeregni" <gms### [at] hotmail com> wrote:
>
> > General algorithms are no good in my opinion.
> > They are recursive and have unintelligent ways.
> > They consume memory.
> > They exaggerate in the points that are already rich and perhaps are deficient in
> > the points that need it most.
>
> What you could do is test the distance between points, and points that are far
> apart can get refined, and points that are close together can get skipped.
>
> However, I'd suggest making it more sophisticated than that - test the curvature
> along some distance on the surface. Flat areas get skipped, and highly curved
> areas get refined. Find some way to appropriately weight the curvature vs
> distance metrics.
>
> Unnecessarily subdivided flat faces could be simplified into a single quad.
>
> Not easy work - very tedious. But well commented code and a flowchart of the
> logic would help in future development.
>
> - BE
You're right, but my goal is more modest. I would leave the rendering engine the
option to adapt the quality to the distance.
Second Life did it many years ago, and I think that more or less all 3D
rendering programs do it.
I don't actually know, in advance, when I create an object for my library, at
what distance it will be seen. I use the library to obtain landscape contexts
where things are as light as possible.
We got into this discussion because jr, rightly, about the BMW, said that
certain parts were too simplified. Even with the smoothing of the triangles. For
this reason, for me it is important to be able to keep the weight of the object
light, but also to have a tool for fine-tuning the critical points.
Implementing mesh enrichment is a good starting point in my opinion. If I want,
when well tested, I could also make it recursive on the entire model.
But it must generate the model. The method we saw is more of a feature of the
render engine, it is volatile. In my opinion it should be addressed at the pov
ray engine level... like "remeshing <SplitValue, WPdistance, etc etc> "
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
For my last version see zip file.
I had hoped a bit for a nice collection of cars and people.
It looks nice, but I'm sure I've done too much work for 3 vehicles and 2 people.
Maybe I'll continue and clean up better, should new models appear.
Ciao
Ma
Post a reply to this message
Attachments:
Download 'gio_250624.zip' (718 KB)
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Here an image will all models
ma
Post a reply to this message
Attachments:
Download 'test_all_01.png' (807 KB)
Preview of image 'test_all_01.png'

|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
"Maetes" <nomail@nomail> wrote:
> Here an image will all models
>
> ma
very nice!
I'm preparing some high definition models, but in the meantime, to be observed
from afar because it's very light, a driver (or a G-man) lol is needed to
monitor the vehicles....
It's a inc, remove the two bottom bars to use it as a standalone pov..
B.R.
G.
Post a reply to this message
Attachments:
Download 'maninblack.zip' (68 KB)
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
hi,
"GioSeregni" <gms### [at] hotmail com> wrote:
> "Maetes" <nomail@nomail> wrote:
> > Here an image will all models
> > ma
> very nice!
>
> I'm preparing some high definition models, but in the meantime, to be observed
> from afar because it's very light, a driver (or a G-man) lol is needed to
> monitor the vehicles....
> It's a inc, remove the two bottom bars to use it as a standalone pov..
thank you ! if, while you're on the exporting things stuff, you could output
the finish with a braced reflection[*], written eg:
finish{ambient .21 diffuse .78 reflection {.01}}
then your code will be correct, and can be used with WFP's 'yuqk' branch/fork.
[*] as documented
<wiki.povray.org/content/Reference:Finish#Specular_Reflection>.
regards, jr.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
"jr" <cre### [at] gmail com> wrote:
> hi,
>
> "GioSeregni" <gms### [at] hotmail com> wrote:
> > "Maetes" <nomail@nomail> wrote:
> > > Here an image will all models
> > > ma
> > very nice!
> >
> > I'm preparing some high definition models, but in the meantime, to be observed
> > from afar because it's very light, a driver (or a G-man) lol is needed to
> > monitor the vehicles....
> > It's a inc, remove the two bottom bars to use it as a standalone pov..
>
> thank you ! if, while you're on the exporting things stuff, you could output
> the finish with a braced reflection[*], written eg:
> finish{ambient .21 diffuse .78 reflection {.01}}
> then your code will be correct, and can be used with WFP's 'yuqk' branch/fork.
>
> [*] as documented
> <wiki.povray.org/content/Reference:Finish#Specular_Reflection>.
>
>
> regards, jr.
I have to apologize because my English is poor and I don't understand the
problem.
Each mesh represents an object that is part of the complete shape, but has its
autonomy, each mesh has its definition of RGB or RGB color with alpha
transparency. The rest of the definition is standard, and can be modified as you
want.
My standard definition does not give me any errors or warnings by Povray, so it
is correct.
It is also easy to modify it, just search on Povray for the keywords -end mesh-
of the comments and modify the previous lines.
The definition is double with the inside because experimenting I saw that this
system hides a bit the artifacts of the smooth_triangle bug. Let's hope they are
solved with the next version of Povray ...
.... please
" WFP's 'yuqk' branch/fork." sorry , what is the meaning? I cannot understand ..
because I don't know these abbreviations
Sorry againg and many thanks ...
BR
G.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|
 |