Le_Forgeron <jgr### [at] freefr> wrote:
> Le 21/10/2011 21:15, H. Karsten nous fit lire :
> > Ok, I changed the concept:
> > Creating a surface is based in two parts, and to realise both within the PovRay
> > language is slow, complicate and not necessary.
> >
> > Only the first part will run insight of PovRay, and it will be MUCH faster!
> > It will create a file, I call .qvx (quick voxel). This file will be taken by a
> > external App, to convert it to a mesh.
>
> Make it a mesh2 syntax, as parsing mesh syntax get slower as bigger the
> mesh is (and it is not with mesh2)
>
> I'm sad you did not read my previous post.

The problem is, that a mesh2 file would need to be optimised, just like a .obj
file.

Optimising means usage of a lot of memory.

Better is, to save it as raw and convert it later. Converter are well optimised
to handle those problems. As well there are lots of apps available that can
build UVs on your meshes.

To do an optimisation on the mesh, is not a task at the moment. The most
important steps for now are speed, and High-res results.

We'll see later if there is more need for adds, for example build a mesh-camera
automatically for baking textures or something.

Best rgds,
Holger

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:
> Le 15/10/2011 04:29, H. Karsten nous fit lire :
> > Here's another one, heaving 100 scans in each axis.
>
> Remind me of my 3.1g version (as a patch, not an inc)
>
> http://jgrimbert.free.fr/pov/patch/tessel/index.html

Would it be very complicate, to compile this into a new version of PovRay?

I tried to compile this, but I'm not a C++ user and with no makefile, I'm
lost...

A lot of people continuously asking for a "converter" from PovRay to other
apps...

I'm wondering that your code did not find it's way into the regular PovRay! As
well, I was asking for micro-poly-displacement in PovRay already long time ago,
and nobody could get me some help..

A lot of good Ideas are still not part of PovRay. Only available as patches.
This is one of the most disadvantages of PovRay ever!

I have installed a big bunch of PovRay versions, only to let run all the
patches...

so I have MegaPov 0.7 & Megapov 1.21. MC-Pov, PovMan SlimePov, ML-Pov,
DensityPov. And now your patch will become another, very good one two.

Ps.: If its to much work for you to put this into a new version ov PovRay, I
like to ask you to do a little howto of the compiling for this. I would like to
have a version, running within cygwin.

Thanx a lot!

Best rgds, Holger

Post a reply to this message

Am 25.10.2011 21:51, schrieb H. Karsten:

> I'm wondering that your code did not find it's way into the regular PovRay! As
> well, I was asking for micro-poly-displacement in PovRay already long time ago,
> and nobody could get me some help..
>
> A lot of good Ideas are still not part of PovRay. Only available as patches.
> This is one of the most disadvantages of PovRay ever!

There are a few reasons contributing to this:

* Including a 3rd-party patch into POV-Ray proper requires the patch to 
be fairly stable, and play well with POV-Ray's traditional features. 
(MC-Pov, for instance, doesn't; for example you can't use both MC-Pov's 
features and conventional light sources at the same time, and MC-Pov's 
diffuse illumination gives significantly different results than 
radiosity due to an error in MC-Pov's math.)

* Including a 3rd-party patch into POV-Ray proper requires some member 
of the dev team to "adopt" the feature for future maintenance (or the 
3rd-party author to credibly commit themselves to future maintenance of 
the feature as part of POV-Ray proper).

* Including a 3rd-party patch into POV-Ray proper requires the patch to 
be compatible with the internal architecture of whatever POV-Ray version 
is currently "in the making"; this is especially a problem with the 
transition from 3.6 to 3.7, which not only changed major portions of the 
architecture, but also took quite a lot of time.

* Including a 3rd-party patch into POV-Ray proper requires the dev team 
to feel that the patch would make a good addition to POV-Ray's portfolio 
of features, without adding too much overhead in case the feature isn't 
used.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
...
> There are a few reasons contributing to this:
>
> * Including a 3rd-party patch into POV-Ray proper requires the patch to
> be fairly stable, and play well with POV-Ray's traditional features.
> (MC-Pov, for instance, doesn't; for example you can't use both MC-Pov's
> features and conventional light sources at the same time, and MC-Pov's
> diffuse illumination gives significantly different results than
> radiosity due to an error in MC-Pov's math.)
>
> * Including a 3rd-party patch into POV-Ray proper requires some member
> of the dev team to "adopt" the feature for future maintenance (or the
> 3rd-party author to credibly commit themselves to future maintenance of
> the feature as part of POV-Ray proper).
>
> * Including a 3rd-party patch into POV-Ray proper requires the patch to
> be compatible with the internal architecture of whatever POV-Ray version
> is currently "in the making"; this is especially a problem with the
> transition from 3.6 to 3.7, which not only changed major portions of the
> architecture, but also took quite a lot of time.
>
> * Including a 3rd-party patch into POV-Ray proper requires the dev team
> to feel that the patch would make a good addition to POV-Ray's portfolio
> of features, without adding too much overhead in case the feature isn't
> used.

OK that makes sense!

tnx,
Holger

Post a reply to this message

"H. Karsten" <h-karsten()web.de> wrote:
> Le_Forgeron <jgr### [at] freefr> wrote:
> > Le 15/10/2011 04:29, H. Karsten nous fit lire :
> > > Here's another one, heaving 100 scans in each axis.
> >
> > Remind me of my 3.1g version (as a patch, not an inc)
> >
> > http://jgrimbert.free.fr/pov/patch/tessel/index.html
>

Not working...

I tried to run e view examples. Sometimes I get segmentation faults and the
examples are not working:



File: http://jgrimbert.free.fr/pov/patch/deform/deform.pov
error:
############################################
Parsing...roll
#break
#end
 {
cristal <----ERROR

test.pov:22: error: Object expected.
############################################



Files: http://jgrimbert.free.fr/pov/patch/deform/deformb.pov
       &
       http://jgrimbert.free.fr/pov/patch/deform/select.pov
Error:
############################################
Parsing...#default { pigment { rgb <1,.8,.6> } finish { specular .5 } }


#declare Objiii =  mesh {
cubicle { box <----ERROR

test.pov:6: error: Object expected.
############################################

any idea?

Best rgds,
Holger

Post a reply to this message

Hi Holger,

This is great news!

I had originally asked about this kind of functionality last year - see 
this post:
http://news.povray.org/povray.general/thread/%3C4b69e9ce$1@news.povray.org%3E/

This potentially opens up lots of opportunities...see this link for more 
information:
http://forums.ldraw.org/read.php?19,1144

Keep up the good work

Reuben

=====================================
Download 3D Lego models and other resources from:
http://www.pearse.co.uk/lego
=====================================


On 15/10/2011 02:44, H. Karsten wrote:
> Hi people,
> I've just started to write a PovRay -.inc file that saves any object, defined in
> PovRay as a mesh -.raw file.
>
> It can save almost everything, include .d3f files (when being used in an
> iso-surface), blobs, meshes, whatever. And can be used in any PovRay or
> PovPatch, supporting the trace() function.
>
> The raw-formate does not have any mesh-optimisation needed. That means, you can
> free chose the resolution, without heaving special high memory installed. It's
> only a matter of time, running the macro.
>
> The only thing (for sure) it can not store "fake-deformations", like coming from
> normal maps on surfaces, or deformed lenses in the camera.
>
> It is still extreme slow, but has very good potential to become optimised.
>
> Here is a simple sphere, having 40 tracking-points in each dimension.
>
> I hope I can release the first version after the weekend :)
>
> Best rgds,
> Holger

Post a reply to this message

Hi Reuben,

funny enough! Because of the Lego-lib, I started all this :)

At the moment, I'm writing the second part in rebol.

The script will take the .qvx file and do the Polys.

My concept for the Lego-animation is, to do the animation in 3d-Studio-Max, then
export the matrix only and PovRay will take the Lego-lib and the matrix and do
the rendering.

It is likely, that we do the same thing, using Blender next and maybe cinema4d
later. Likely as well is Houdini.

The Script on the PovRay-side is all most done. I've used this technique
already, using mesh2 objects insight PovRay.
See: http://lightspeed.byethost24.com/ for some examples.

The only difference in the PovRay-script in the future is that some objects can
be completely missing, or off in the matrix and that's just a very little thing
to do.

I hope the Rebol-script is done in a view days.

The example-script I've posted before is to slow. The new thing can be more then
1000 times faster. So better for you to wait a view more days :)

Best rgds,
Holger

Post a reply to this message

On 10/25/2011 1:42 PM, clipka wrote:
> Am 25.10.2011 21:51, schrieb H. Karsten:
>
>> I'm wondering that your code did not find it's way into the regular
>> PovRay! As
>> well, I was asking for micro-poly-displacement in PovRay already long
>> time ago,
>> and nobody could get me some help..
>>
>> A lot of good Ideas are still not part of PovRay. Only available as
>> patches.
>> This is one of the most disadvantages of PovRay ever!
>
> There are a few reasons contributing to this:
>
> * Including a 3rd-party patch into POV-Ray proper requires the patch to
> be fairly stable, and play well with POV-Ray's traditional features.
> (MC-Pov, for instance, doesn't; for example you can't use both MC-Pov's
> features and conventional light sources at the same time, and MC-Pov's
> diffuse illumination gives significantly different results than
> radiosity due to an error in MC-Pov's math.)
>
> * Including a 3rd-party patch into POV-Ray proper requires some member
> of the dev team to "adopt" the feature for future maintenance (or the
> 3rd-party author to credibly commit themselves to future maintenance of
> the feature as part of POV-Ray proper).
>
> * Including a 3rd-party patch into POV-Ray proper requires the patch to
> be compatible with the internal architecture of whatever POV-Ray version
> is currently "in the making"; this is especially a problem with the
> transition from 3.6 to 3.7, which not only changed major portions of the
> architecture, but also took quite a lot of time.
>
> * Including a 3rd-party patch into POV-Ray proper requires the dev team
> to feel that the patch would make a good addition to POV-Ray's portfolio
> of features, without adding too much overhead in case the feature isn't
> used.

Still, its the only case I have seen of something that kind of manages 
something I wish I could do. I am looking at a situation where:

1. I am not too good at texture, but OK at building, so a lot of the 
"detail" would be easier to do by adding parts, rather than texturing.

2. I need it to be in a form that can be imported to something that 
isn't POV-Ray.

3. Some sort of "level of detail" trick would be nice to have.

The perfect way to do this, as I see it, would be to have something like 
this trace. You generate 3 levels of detail, limiting the amount of 
geometry you create. You use object patterns, or the like, to generate 
the texture. I.e., you convert geometry that falls outside the bounds of 
the level of detail you want into object pattern, so you still get the 
same "detail", but its mapped to the object texture, not actual mesh detail.

You can "sort of" get LOD in other applications, you have to do it 
manually, and you can't "map" the missing geometry onto the simpler 
model. And, for course, the smallest levels of detail have to be an 
image, since you can't project those tiny details into a UV mapped image 
directly (or even, if supported, shadow maps, plus image). For someone 
like me, it would be brilliant if this sort of thing was more direct. 
But, even without it, it would still be bloody nice to build using 
primitives, and have the program generate a final mesh, which removes 
all the bits I don't need. Easy to do, automatically, via POV-Ray, since 
it uses CSG. A bloody pain in the ass in all those "super duper powerful 
mesh editors". lol And, as far as I know, no one has even attempted what 
I describe above.

I am not looking forward to trying to do it the harder way. :p

Post a reply to this message

I think that an answer to that would be a new version of Moray: Build in 
csg then convert to mesh. The current version does already that but 
could be improved, for instance with the techniques shown here.

Thomas

Post a reply to this message

You forget Moray, which basically can convert csg to mesh, although the 
technique could be much improved imo.

Thomas

Post a reply to this message