 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 17-6-2013 16:30, LanuHum wrote:
> No! Povray bad work with mesh
On the contrary, POV-Ray works perfectly with meshes. It is the quality
of the meshes that may be a problem, for instance when triangle vertices
are not welded.
I recommend that - before rendering in POV-Ray - you pass your Blender
mesh through Poseray ( https://sites.google.com/site/poseray/ ). There,
you can weld the loose vertices, subdivide the mesh, etc. Then, you can
export in mesh2 format and render in POV-Ray.
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot <tho### [at] degroot org> wrote:
> On 17-6-2013 16:30, LanuHum wrote:
> > No! Povray bad work with mesh
>
> On the contrary, POV-Ray works perfectly with meshes. It is the quality
> of the meshes that may be a problem, for instance when triangle vertices
> are not welded.
>
> I recommend that - before rendering in POV-Ray - you pass your Blender
> mesh through Poseray ( https://sites.google.com/site/poseray/ ). There,
> you can weld the loose vertices, subdivide the mesh, etc. Then, you can
> export in mesh2 format and render in POV-Ray.
>
> Thomas
It is a bad way! If animation?
Povray reads simple text the file.
This file can be created in Poseray, and I can write just the same file hands.
It is necessary to know a mistake.
Mesh created in Blender, without problems is read by other renderer: Luxrender,
Yafaray. There are no problems as with export to OBJ.
You could find the wrong ranges in the example given by me?
Where there triangle vertices are not welded.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> It is a bad way! If animation?
Yes in case of an animation this isn't a good idea. In case of a still it is the
way to go. As Alain mentioned your problem is with the media settings. The first
example uses an extinction value of 0.01 the second 4.871. The first scene has
30 samples within cube_001 the second 256 and there are some different settings
with the light_sources. These settings causes the prolonged rendering time.
Thomas mentioned problems with bad defined meshes which is true in general, but
not with your simple ones here. You have only a cube and such but not Lucy. I
think he only tried to give you an other hint, what could be got wrong from his
long time experience with POV.
But your problem comes from your settings for the scattering media. May be you
have misunderstood some parametrisations within Blender or there is a bug within
the exporter from Blender to POV. I propose to ask the Blender Community as
well.
Best regards,
Michael
BTW: Your first scene took 7 min 40 sec at my (new) system, the second is at 2%
after 20 min. So I can reproduce your problem. I used the scattering values from
the first scene for the second and yielded rendering times close to the first,
but unfortunatelly another lighting. Excuse me, that I cannot go further into
this issue, since I have my own renderings pending.
Post a reply to this message
|
|
| |
| |
|
|
From: Thomas de Groot
Subject: Re: Very big time difference of a render
Date: 19 Jun 2013 08:43:03
Message: <51c1a757@news.povray.org>
|
|
|
| |
| |
|
|
On 18-6-2013 20:43, MichaelJF wrote:
>
>> It is a bad way! If animation?
>
> Yes in case of an animation this isn't a good idea. In case of a still it is the
> way to go.
I do not see the problem in the case of an animation, as Poseray is only
used once, before any animation is started...
But that leads us away from the thread's topic doesn't it? ;-)
As Alain mentioned your problem is with the media settings. The first
> example uses an extinction value of 0.01 the second 4.871. The first scene has
> 30 samples within cube_001 the second 256 and there are some different settings
> with the light_sources. These settings causes the prolonged rendering time.
Media samples can certainly be brought down. Additionally, there seems
to be a /coincident surface/ problem with the wall at left, judging from
the artefacts there.
> Thomas mentioned problems with bad defined meshes which is true in general, but
> not with your simple ones here. You have only a cube and such but not Lucy. I
> think he only tried to give you an other hint, what could be got wrong from his
> long time experience with POV.
Just to say that POV-Ray and meshes (mesh2 in particular) work very well
together :-)
The meshes from Blender look OK but I am no expert on Blender and its
exporter to POV-Ray.
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I don't know how you managed to get this media sample count from the official
blender exporter since the media samples allowed by its interface are a maximum
number of 100.
About the pigment_pattern with image map slowdown, how much does it really slow
things down? Because that's really needed to get to more complex texture
influence export corner cases like specular mapping with a texture. To
implement scripted conditions that detect more cleverly the complexity of the
scene in original file and export only with necessary features, I need to know
how much speed could be gained, and if it's really worth it.
Anyway, LanuHum, this is a very interesting type of comparison to improve the
exporter. there could be such tests for many other features with very simple
scenes also usefull to spot regressions of exporter versions. I think I did put
a few scenes on the exporter wiki for that already and I might have a few others
on my local drive at home. ask me by mail if you want them and please could you
also send me any updates to your version of the script when you manage to get it
closer to the official one so that I can try to merge the two versions.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Mr" <nomail@nomail> wrote:
> I don't know how you managed to get this media sample count from the official
> blender exporter since the media samples allowed by its interface are a maximum
> number of 100.
>
> About the pigment_pattern with image map slowdown, how much does it really slow
> things down? Because that's really needed to get to more complex texture
> influence export corner cases like specular mapping with a texture. To
> implement scripted conditions that detect more cleverly the complexity of the
> scene in original file and export only with necessary features, I need to know
> how much speed could be gained, and if it's really worth it.
>
> Anyway, LanuHum, this is a very interesting type of comparison to improve the
> exporter. there could be such tests for many other features with very simple
> scenes also usefull to spot regressions of exporter versions. I think I did put
> a few scenes on the exporter wiki for that already and I might have a few others
> on my local drive at home. ask me by mail if you want them and please could you
> also send me any updates to your version of the script when you manage to get it
> closer to the official one so that I can try to merge the two versions.
I work over the exporter.
I don't hope that the official version will reach functionality.
I change limits, studying Povray documentation.
I have not enough time
In detail on Saturday or on Sunday, on days off
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 18-6-2013 20:43, MichaelJF wrote:
>>
>>> It is a bad way! If animation?
>>
>> Yes in case of an animation this isn't a good idea. In case of a still it is the
>> way to go.
>I do not see the problem in the case of an animation, as Poseray is only
>used once, before any animation is started...
I think we have a misunderstanding here. My idea was, that the animation is done
within Blender. Blender will produce a POV-Scene for every frame and you have to
pass every Blender output frame through PoseRay, what is a little bit
inconvient. If the animation is done with POV you have to pass only the initial
scene through PoseRay. But I fear no Blender user will do so, since Blender is
designed to do animations. POV can do animations but it is not designed for it.
> But that leads us away from the thread's topic doesn't it? ;-)
Yes, in a way. But I judge the original topic as solved. So we can drift off a
little bit.
>> Thomas mentioned problems with bad defined meshes which is true in general, but
>> not with your simple ones here. You have only a cube and such but not Lucy. I
>> think he only tried to give you an other hint, what could be got wrong from his
>> long time experience with POV.
>Just to say that POV-Ray and meshes (mesh2 in particular) work very well
>together :-)
Yes indeed, and it can handle bad welded meshes. I understand this as meshes
which having repeated vertices, edges or overlapping faces. I cannot see a
performance breakdown at the scale mentioned here. Best known example for
repeated vertices is the sky dome created by Lightsys "CIE Skylight". I never
had a problem with it.
Best regards,
Michael
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> About the pigment_pattern with image map slowdown, how much does it really slow
> things down? Because that's really needed to get to more complex texture
> influence export corner cases like specular mapping with a texture. To
> implement scripted conditions that detect more cleverly the complexity of the
> scene in original file and export only with necessary features, I need to know
> how much speed could be gained, and if it's really worth it.
>
>
This can vary greatly. It all depends on the complexity of the
controling pattern and what you do with it.
Whenever you have any ..._map, there is some blending and averaging
done. Everywhere outside the values that are explicitely provided, you
need to evaluate at least 2 pigments, textures or normals, and ponderate
each according to it's contribution. The worst case been an average_map
of full textures with normals, reflection and transparency.
A best case:
pigment_map{[0.5 Pigment1][0.5 Pigment2]}
pigment_map{[0.25 Pigment1][0.25 Pigment2][0.5 Pigment2][0.5
Pigment3][0.75 Pigment3][0.75 Pigment4]}
No notable slowdown, from 0 to 0.5, you use only Pigment1, and from 0.5
to 1, it's only Pigment2. Here, it don't mather how many entries there
are, as long as each transitions are abrupt.
Worst case:
texture{average{[1 texture Texture1][1 texture Texture2]...[1 texture
Texture255]]
About 255 times slower as all 255 textures need to be evaluated and
averaged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 19-6-2013 22:14, MichaelJF wrote:
> I think we have a misunderstanding here. My idea was, that the animation is done
> within Blender. Blender will produce a POV-Scene for every frame and you have to
> pass every Blender output frame through PoseRay, what is a little bit
> inconvient. If the animation is done with POV you have to pass only the initial
> scene through PoseRay. But I fear no Blender user will do so, since Blender is
> designed to do animations. POV can do animations but it is not designed for it.
Ouch. Stupid me. Forgot about /Blender/ animations... :-)
>> Just to say that POV-Ray and meshes (mesh2 in particular) work very well
>> together :-)
>
> Yes indeed, and it can handle bad welded meshes. I understand this as meshes
> which having repeated vertices, edges or overlapping faces. I cannot see a
> performance breakdown at the scale mentioned here. Best known example for
> repeated vertices is the sky dome created by Lightsys "CIE Skylight". I never
> had a problem with it.
Also correct. Bad meshes can create other problems than the ones
mentioned here indeed. I was wondering in fact about their behaviour in
combination with media and/or photons, e.g. with inconsistent normal
orientations.
Thomas
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Mr" <nomail@nomail> wrote:
> I don't know how you managed to get this media sample count from the official
> blender exporter since the media samples allowed by its interface are a maximum
> number of 100.
>
> About the pigment_pattern with image map slowdown, how much does it really slow
> things down? Because that's really needed to get to more complex texture
> influence export corner cases like specular mapping with a texture. To
> implement scripted conditions that detect more cleverly the complexity of the
> scene in original file and export only with necessary features, I need to know
> how much speed could be gained, and if it's really worth it.
>
> Anyway, LanuHum, this is a very interesting type of comparison to improve the
> exporter. there could be such tests for many other features with very simple
> scenes also usefull to spot regressions of exporter versions. I think I did put
> a few scenes on the exporter wiki for that already and I might have a few others
> on my local drive at home. ask me by mail if you want them and please could you
> also send me any updates to your version of the script when you manage to get it
> closer to the official one so that I can try to merge the two versions.
Initially:
Why I started working with Povray?
I was interested by possibility of application to object of several materials
with various characteristics:Glass with a color pattern, on it mirror patterns
from silver, on mirror patterns blackening (oxygenating)
Blender internal render is able to draw it, but without photons, without
caustic, without iridescence
Povray is able to draw it, with photons, with caustic, with iridescence.
For this purpose it is necessary to use textural maps
I turned on at once two maps in function of write of the file, it is so simpler
to operate process automatically
If material 1, textural map: rgb 0, if materials 2 - textural map: image
If material 1 and textural map: rgb 0 - can, it not rational (record or write),
but this process doesn't take a lot of time, but relieves the programmer of a
difficult code
Now for me the main problem - to create a preview of the patterns built in
Povray by means of any crutch as I am not a professional in the field of
programming. It is simple my hobby, I don't know much.
After that it will be necessary to clear, correct errors, to establish rational
parameters by default, and, it will be possible to try to create very good
scenes
My version of the exporter is based on the official version, I didn't write a
code from a blank sheet, but... the official version seeks to tie the Povray
parameters to the Blender parameters that absolutely irrationally and doesn't
allow to use all capacity or Povray force
I connect the Povray parameters with the Blender parameters only to create a
preview of materials in Blender. The preview of the materials surface with
textures like image from file is already available:
http://yadi.sk/d/I4Dk-4G063iaU
If my work is interesting to you and there are questions, you can contact me
having written to me here:
Lan### [at] yandexru
But, you remember, I use an online translator for communication with
English-speaking people of our planet
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
