POV-Ray : Newsgroups : povray.binaries.images : Tinkering with textures Server Time
17 May 2024 16:18:55 EDT (-0400)
  Tinkering with textures (Message 52 to 61 of 71)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>
From: architype
Subject: Re: Tinkering with textures
Date: 13 Aug 2016 17:55:02
Message: <web.57af970f68edbca096ba01200@news.povray.org>
And with light coming from the side... /A


Post a reply to this message


Attachments:
Download 'andreamain_r03_ret.jpg' (493 KB)

Preview of image 'andreamain_r03_ret.jpg'
andreamain_r03_ret.jpg


 

From: Thomas de Groot
Subject: Re: Tinkering with textures
Date: 14 Aug 2016 02:47:08
Message: <57b013ec@news.povray.org>
That is pretty good.

-- 
Thomas


Post a reply to this message

From: Stephen
Subject: Re: Tinkering with textures
Date: 14 Aug 2016 04:54:39
Message: <57b031cf$1@news.povray.org>
On 8/13/2016 12:20 PM, architype wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> This is going to look like an illustration from a typical Renaissance
>> architectural text book ;-)
>>
>> --
>> Thomas
>
> That is what I am hoping for. I pinched the foreground idea from Serlios book:
>
http://1.bp.blogspot.com/-Uh7zFQhEeb0/VLjkNK1nNTI/AAAAAAAADQk/Jmf0Mp9vTVY/s1600/serlio6%2B(2).jpg
>
> It seems lame to put work into my own bad ideas when I can realize other peoples
> good ideas... ;)
>
> Best wishes, /A
>
>

I think that you have picked a subject that will keep you busy for some 
years to come. :)

Please keep us updated.

-- 

Regards
     Stephen


Post a reply to this message

From: architype
Subject: Re: Tinkering with textures
Date: 14 Aug 2016 15:20:01
Message: <web.57b0c3bb68edbca0cdd20bad0@news.povray.org>
> That is pretty good.

Thanks! :)

This is the building I am after:
https://s-media-cache-ak0.pinimg.com/736x/7f/d0/6c/7fd06c2d2bca8f3dab6e9c8a24c2b072.jpg
https://upload.wikimedia.org/wikipedia/commons/f/fb/MantovaBasilicaSantAndrea_cutnpaste_over_intrusions.jpg

The elevation really shows off the excellent design.
The good part is of course that if there is one thing I can do, it is
modelling architecture. ;)
I might not have time to do all the details exactly right, but I will
be able to do a good model with decent textures. Hoping that you will
give me some much needed advice about textures when we get that far...


>I think that you have picked a subject that will keep you busy for some
>years to come. :)

>Please keep us updated.


Yeah, I would be pleased if I can finish this scene and part of the
library by the end of 2016...
I have been working on classical architecture on and off since before
2000 and it wasn't until about 2010 that I had gained the experience and
got the skills needed to create the things I really wanted.
But I have not had as much time as I would have like to, so I only have
a few good models in my portfolio...

Also, I certainly don't have the skill to design original buildings, but
I have some knowledge of proportion, and I can recognize a good building
when I see it.
It remains to be seen how well I can compose... ;) But I am fairly sure
that the three main buildings I have chosen work well together; ie one
with a giant order, one on a rusticated ground floor and one with only
a little plasticity.

The problem with the attached image is not so much about modelling and
design I think, but more about (relative) scale, placement and the light.
The tower is still annoying for example, but if it was a little higher
and further back it could work for the time being.

I will post screenshots as the project progresses. :)

Best wishes, /A


Post a reply to this message


Attachments:
Download 'rusticscenecaprini_leftbuild _ light left ret.jpg' (1303 KB)

Preview of image 'rusticscenecaprini_leftbuild _ light left ret.jpg'
rusticscenecaprini_leftbuild _ light left ret.jpg


 

From: architype
Subject: Re: Tinkering with textures
Date: 15 Aug 2016 00:45:01
Message: <web.57b147ef68edbca0591d436f0@news.povray.org>
This is also an interesting possibility. :) /A


Post a reply to this message


Attachments:
Download 'rusticscenecaprini_leftbuild _ light back 2.jpg' (547 KB)

Preview of image 'rusticscenecaprini_leftbuild _ light back 2.jpg'
rusticscenecaprini_leftbuild _ light back 2.jpg


 

From: Bald Eagle
Subject: Re: Tinkering with textures
Date: 16 Aug 2016 20:10:00
Message: <web.57b3ab2268edbca05e7df57c0@news.povray.org>
"architype" <arc### [at] gmxcom> wrote:

> [...] it would be great if
> others could help with textures, finishes and rendering & lighting, I am
> particularly weak in those areas.

I spent a lot of time on an architectural project a while back - learned a lot,
and discovered how much more there is to learn.
I didn't use a modeler or meshes - it's all hand-coded CSG.

You seem to have a good working knowledge of using normals - I'd have to say I'm
pretty weak in that area.

https://postimg.org/gallery/5q2y5zuu/
http://news.povray.org/povray.binaries.images/thread/%3Cweb.5429f3c0df0b11825e7df57c0@news.povray.org%3E/?ttop=403012&t
off=100

> But I can make a medium detail model of the scene, that is my first milestone.

Perhaps if you could put the macros and such into a structured directory in a
zip file, then I could implement them a lot faster, and see what you've got and
where things can go from there.

I'm curious about what your overall idea is about creating the structures -
especially the open spaces like windows, doors, etc.
Are you envisioning a modular sort of architectural toolkit, where pieces are
added at the appropriate places to make up the whole?

> When that is complete we can look into textures, lightsources and detailed
> modelling of the most visible parts. :)
> Best wishes! /A

That sounds like something that would be very nice in the end.


Post a reply to this message

From: architype
Subject: Re: Tinkering with textures
Date: 17 Aug 2016 10:15:01
Message: <web.57b4707168edbca0571874170@news.povray.org>
>I spent a lot of time on an architectural project a while back - learned a lot,
>and discovered how much more there is to learn.
>I didn't use a modeler or meshes - it's all hand-coded CSG.

>You seem to have a good working knowledge of using normals - I'd have to say I'm
>pretty weak in that area.

>https://postimg.org/gallery/5q2y5zuu/
>http://news.povray.org/povray.binaries.images/thread/%3Cweb.5429f3c0df0b11825e7df57c0@news.povray.org%3E/?ttop=403012&
t
>off=100

Those look pretty good! :)
Btw I took a look at the pov-ray docs and it turns out you can add "normal on"
in the radiosity statement and get normals to work.
I havent had time to do a test image yet.

What would you like to do btw, we could split the scene into buildings/sections
and write a few ones each? I could do the rusticated one on the left and the
church with vault and pediment? As long as those two are in the scene we can
tinker with the rest and you can chose what you like to model?

>Perhaps if you could put the macros and such into a structured directory in a
>zip file, then I could implement them a lot faster, and see what you've got and
>where things can go from there.

I wrote a program in pascal/delphi/lazarus that extracts all files necessary for
the
scene from my library and dumps them into a single unstructured folder.
I know it is a bit annoying to have all the files in the same folder, but it is
not so bad since you can navigate by right clicking the include file and
pressing
"Open ...". And since all my .inc files have a default camera that can be
accessed
by setting the debug switch to 1 it should be workable. It just needs a little
documentation so you know which file is the main scene.
I dont have time to mess with the new code right now, it must be fleshed out,
cleaned up and have some docs added, before it is meaningful to upload it.

(If you want to get a feel for the workflow you can tinker with the other code I
uploaded: http://cdn-cms.f-static.com/uploads/61867/normal_579c48f086009.zip
Unzip and place AT_Aachen in the documents folder, open
UnderConstructionMain2_9.inc with povray and turn off radiosity, then you can
render & navigate using the right click open #include file method. There are
some
columns and vaults that might be reused.)

You could also use my base library of reusable components, and an incomplete
insert menu. But it is undocumented and the workflow is sort of fixed...
(I dont want to upload it for everyone to download but I could mail it to you
along with some docs/comments. If you want to try it out you can use the email
at the bottom of the page: http://povscriptcode.site123.me/
There are also some images with ideas for the scene on the webpage.)

>I'm curious about what your overall idea is about creating the structures -
>especially the open spaces like windows, doors, etc.
>Are you envisioning a modular sort of architectural toolkit, where pieces are
>added at the appropriate places to make up the whole?

Unfortunately there is no overall idea, just the primitive urge to model... ;-)
[s]and voices in my head telling me what to do...[/s]
I have some code and I intend to extend it with the rustic stone library.
As for windows, I normally dont spend that much time on them and usually only
make a simple frame and perhaps some glass.
Yes the idea is to do a modular architectural toolkit eventually, but it is
such a big undertaking so right now I will make use of what I got and just do
some design of the rustic library and implement just enough to get the first
scene done.
Also design can be very tricky, as I have learned the hard way... first there
is the balance between ease of use and control over details.
Second between the features you want and the features that are easy/possible to
implement...
Third there is ease of implementation contra writing code that is efficient to
use/runs fast.
When it comes to meshes it means keeping the numbers down and removing those
that do not belong/overlap/are not visible.
Also when it comes to CSG there are several ways to hack it, keeping down use
of difference, try and limit difference operations to cutting with planes.
Also avoid cutting complex shapes such as unions. Making complex shapes as a
union of basic elements rather than a single difference etc.

I am very interested in this stuff so I look forward to go through it in detail
when I write the rustic btm story on the left.

I have also tried out the sketchup to povray thingy and so far its looking good.
:)
I have had some annoying texture bugs though which detracts from the value.
And its annoying not to have access to parameters, I use the free version of
sketch,
but some shapes and objects are just very hard to do in povray, so its nice to
know that there is a working modelling tool.
One quick and dirty hack I have in mind is placing houses, ie write a box
component
and then arrange them neatly. Convert to pov and replace the box component with
a
detailed pov component. That would be neat if it worked.
The attached image took about 1.5h to create in sketchup and then export to pov,
which is nice, but it cannot "do" any more than just sit there... :p
How much the blocks extrude can be manipulated by scaling, but I really want the
the gap between the blocks as a parameter, it is too hard to choose that in the
beginning and not be able to alter it later.

But I need to put some more thought into design first. For example it might be
necessary to have 2 parameters for level of detail; one for modelling and one
for texture. (Ie you might want to skip the trees when testing, but maybe the
full detail texture needs to be shown, ie with normal etc)
And should the component only pass its parameter on to the sub components?
(It might not be that easy, for at some level, small components should
probably not be drawn at all. Showing also that there should be an LOD = -1
which means do not load or draw at all.)

What is it they say about relations; "Its complicated" ;)

Best wishes, /A


Post a reply to this message


Attachments:
Download 'caprinibtm_suver7_mdl010.jpg' (109 KB)

Preview of image 'caprinibtm_suver7_mdl010.jpg'
caprinibtm_suver7_mdl010.jpg


 

From: Bald Eagle
Subject: Re: Tinkering with textures
Date: 17 Aug 2016 12:55:00
Message: <web.57b4963068edbca0b488d9aa0@news.povray.org>
"architype" <arc### [at] gmxcom> wrote:

> Those look pretty good! :)

Thanks - I think that took about 3 months, and it could look a lot better.

> Btw I took a look at the pov-ray docs and it turns out you can add "normal on"
> in the radiosity statement and get normals to work.

Read the docs, eh?
'round here we call that _cheating_   ;)
Next thing we know, you'll be reading the source code....

> What would you like to do btw,

I think I'd like to help work out some of the planning / workflow / code
aspects, and work on a building or feature or three to give me something
specific as a goal.


> And since all my .inc files have a default camera that can be
> accessed
> by setting the debug switch to 1 it should be workable.
> It just needs a little
> documentation so you know which file is the main scene.

I generally use a .pov file for the main scene, and use .inc or .mcr files for
defining specific complex objects or writing larger macros that are best left
out of the main scene file for clarity.
I don't use a manual switch so much as I let the scene determine automatically
if it's a sub-portion or standalone.
I define a variable called SDL, and then in the .inc file, I check if it's
defined.  If it is, then the include file is being called as an .inc, if it's
not, then I'm working on the .inc file and I want to render it as a standalone
scene, so I invoke all of the usual camera, lightsource, skysphere stuff in the
#else section.


> Unfortunately there is no overall idea, just the primitive urge to model... ;-)
> [s]and voices in my head telling me what to do...[/s]

A kindred spirit, I see.   ;)


> As for windows, I normally dont spend that much time on them and usually only
> make a simple frame and perhaps some glass.

I was just asking, since it's often hard to "go back" and add a window when
you're making modular constructs, or a window in one segment can be covered by
another...


> Yes the idea is to do a modular architectural toolkit eventually, but it is
> such a big undertaking so right now I will make use of what I got and just do
> some design of the rustic library and implement just enough to get the first
> scene done.


I hear what you're saying, and there is definite logic and value to producing a
_fait accompli_ as proof of concept.

I need to look at Chris Colefax's city macro to see what he does to make very
large numbers of random buildings at a distance.

> Also design can be very tricky, as I have learned the hard way... first there
> is the balance between ease of use and control over details.
> Second between the features you want and the features that are easy/possible to
> implement...
> Third there is ease of implementation contra writing code that is efficient to
> use/runs fast.
> When it comes to meshes it means keeping the numbers down and removing those
> that do not belong/overlap/are not visible.

I've been looking at "frustrum clipping" here:
http://paulbourke.net/miscellaneous/povexamples/
and need to work out what's going on so that I can do things like determine
what's in the camera view, etc.   Then eliminating nonessential objects can be
automated to some extent.
It would also be great to write an .pov file for new users so that they can SEE
how changing camera values has an effect on the scene, and see the interplay
between right, up, angle, etc.


> One quick and dirty hack I have in mind is placing houses, ie write a box
> component
> and then arrange them neatly. Convert to pov and replace the box component with
> a
> detailed pov component. That would be neat if it worked.

Sound like it ought to work splendidly.


> But I need to put some more thought into design first. For example it might be
> necessary to have 2 parameters for level of detail; one for modelling and one
> for texture. (Ie you might want to skip the trees when testing, but maybe the
> full detail texture needs to be shown, ie with normal etc)
> And should the component only pass its parameter on to the sub components?
> (It might not be that easy, for at some level, small components should
> probably not be drawn at all. Showing also that there should be an LOD = -1

I think a lot of that can be handled in a "control panel" at the top of the main
scene.   Just wrap certain scene items in an #if #end block, and select or
deselect them.   There are also POV-Ray's render Quality levels that can be
invoked.

Work stuff like that in early on, and it makes it a lot easier to incorporate it
into the code / workflow and be thinking that extra step or two ahead when
coding a scene.


P.S.
I have just managed to make some mesh spheres starting from either an octahedron
or an icosahedron - still a few small bugs I need to work out, and then maybe
that might be of use for certain scene elements.


Post a reply to this message

From: architype
Subject: Re: Tinkering with textures
Date: 18 Aug 2016 00:55:01
Message: <web.57b53f1c68edbca0aa0fd4820@news.povray.org>
> > Those look pretty good! :)
>
> Thanks - I think that took about 3 months, and it could look a lot better.
>

I can imagine that. I also find that I run out of time to make a better
scene, really use the models to their full potential.

> > Btw I took a look at the pov-ray docs and it turns out you can add "normal on"
> > in the radiosity statement and get normals to work.
>
> Read the docs, eh?
> 'round here we call that _cheating_   ;)
> Next thing we know, you'll be reading the source code....
>

Yeah software is supposed to be intuitive and the good stuff is. And I often
tend to do without the manual. That or I stop using it. :p
But povray really needs some explanaition of course, since the subject is a
little complex...

> > What would you like to do btw,
>
> I think I'd like to help work out some of the planning / workflow / code
> aspects, and work on a building or feature or three to give me something
> specific as a goal.
>

So, a little of everything, just like me. :)


> > And since all my .inc files have a default camera that can be
> > accessed
> > by setting the debug switch to 1 it should be workable.
> > It just needs a little
> > documentation so you know which file is the main scene.
>
> I generally use a .pov file for the main scene, and use .inc or .mcr files for
> defining specific complex objects or writing larger macros that are best left
> out of the main scene file for clarity.
> I don't use a manual switch so much as I let the scene determine automatically
> if it's a sub-portion or standalone.
> I define a variable called SDL, and then in the .inc file, I check if it's
> defined.  If it is, then the include file is being called as an .inc, if it's
> not, then I'm working on the .inc file and I want to render it as a standalone
> scene, so I invoke all of the usual camera, lightsource, skysphere stuff in the
> #else section.
>

Interesting. The reason I can do without an SDL variable is that all my stuff
is created at <0,0,0> and that I have some parameters for the camera, ie
location and look at.
About the .pov file; I really should do it your way, but often testing of the
main .inc file degenerates into creating the final scene... ;)
But there is also a point with making everything an .inc because there are so
many files and so many layers of folders.
(The base lib has 1000+ files and more than 6 layers of folders; ie a scene has
multiple buildings, a building has multiple components, each component has
several elements, each element is broken into moulds and those in turn into the
basic shapes like cylinder and box...)


>
> > Unfortunately there is no overall idea, just the primitive urge to model... ;-)
> > [s]and voices in my head telling me what to do...[/s]
>
> A kindred spirit, I see.   ;)
>

Absolutely. :)
>
> > As for windows, I normally dont spend that much time on them and usually only
> > make a simple frame and perhaps some glass.
>
> I was just asking, since it's often hard to "go back" and add a window when
> you're making modular constructs, or a window in one segment can be covered by
> another...
>

That is probably true, even though I havent had that particular problem yet.
The trouble for me has been version control and having to update lots of #macro
calls when I wanted to add more parameters.

>
> > Yes the idea is to do a modular architectural toolkit eventually, but it is
> > such a big undertaking so right now I will make use of what I got and just do
> > some design of the rustic library and implement just enough to get the first
> > scene done.
>
>
> I hear what you're saying, and there is definite logic and value to producing a
> _fait accompli_ as proof of concept.
>
> I need to look at Chris Colefax's city macro to see what he does to make very
> large numbers of random buildings at a distance.

That sounds interesting.

>
> > Also design can be very tricky, as I have learned the hard way... first there
> > is the balance between ease of use and control over details.
> > Second between the features you want and the features that are easy/possible to
> > implement...
> > Third there is ease of implementation contra writing code that is efficient to
> > use/runs fast.
> > When it comes to meshes it means keeping the numbers down and removing those
> > that do not belong/overlap/are not visible.
>
> I've been looking at "frustrum clipping" here:
> http://paulbourke.net/miscellaneous/povexamples/
> and need to work out what's going on so that I can do things like determine
> what's in the camera view, etc.   Then eliminating nonessential objects can be
> automated to some extent.
> It would also be great to write an .pov file for new users so that they can SEE
> how changing camera values has an effect on the scene, and see the interplay
> between right, up, angle, etc.
>

Frustrum clipping seem interesting.
Yes, I really should follow the .pov standard.

>
> > One quick and dirty hack I have in mind is placing houses, ie write a box
> > component
> > and then arrange them neatly. Convert to pov and replace the box component with
> > a
> > detailed pov component. That would be neat if it worked.
>
> Sound like it ought to work splendidly.
>

I will test and report.

>
> > But I need to put some more thought into design first. For example it might be
> > necessary to have 2 parameters for level of detail; one for modelling and one
> > for texture. (Ie you might want to skip the trees when testing, but maybe the
> > full detail texture needs to be shown, ie with normal etc)
> > And should the component only pass its parameter on to the sub components?
> > (It might not be that easy, for at some level, small components should
> > probably not be drawn at all. Showing also that there should be an LOD = -1
>
> I think a lot of that can be handled in a "control panel" at the top of the main
> scene.   Just wrap certain scene items in an #if #end block, and select or
> deselect them.   There are also POV-Ray's render Quality levels that can be
> invoked.

Hmmmm I am not sure it is that simpe given the structure of my code, I have
sometimes made an .inc file with global variables but that is a messy approach.

>
> Work stuff like that in early on, and it makes it a lot easier to incorporate it
> into the code / workflow and be thinking that extra step or two ahead when
> coding a scene.
>

That is solid advice.

>
> P.S.
> I have just managed to make some mesh spheres starting from either an octahedron
> or an icosahedron - still a few small bugs I need to work out, and then maybe
> that might be of use for certain scene elements.

That should be very useful, I saw your other threads.

Best wishes, /A


Post a reply to this message

From: architype
Subject: Re: Tinkering with textures
Date: 19 Aug 2016 12:55:01
Message: <web.57b7398c68edbca04c79588f0@news.povray.org>
I had some time to spare today, so I decided to put together another building.
Its not as good as the inspirational image but it is okay, and besides the
light settings make it look more interesting than it really is. ^_^


Post a reply to this message


Attachments:
Download 'screenbuilding_r001.png' (577 KB)

Preview of image 'screenbuilding_r001.png'
screenbuilding_r001.png


 

<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.