 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 03/08/2014 13:22, LanuHum wrote:
> I will tell about it to users of Windows.
> Let them study source codes and cygwin.
> :)
>
I would rather eat cake!
:-)
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 03.08.2014 20:33, schrieb Alain:
>> Le_Forgeron <jgr### [at] free fr> wrote:
>>> No gui: try to have the unix/linux code in a windows port, via thing
>>> like cygwin.
>>>
>>> --
>>> IQ of crossposters with FU: 100 / (number of groups)
>>> IQ of crossposters without FU: 100 / (1 + number of groups)
>>> IQ of multiposters: 100 / ( (number of groups) * (number of groups))
>>
>> There is no such option in Povray for Windows?
>> I will tell about it to users of Windows.
>> Let them study source codes and cygwin.
>> :)
>
> It's possibly the same for the MacOS version.
Kind of, I guess (I've never used it myself, due to a lack of a Mac ;-))
-- but there's a command-line only version for MacOS.
The lack of a command-line only version for Windows is a legacy of acts
of software piracy, where companies would use POV-Ray as the rendering
engine in their products without so much as giving any credits, let
alone informing their users that they could get the render engine for
free. As a consequence, the copyright owners of POV-Ray had at some time
decided to effectively forbid the distribution of any POV-Ray version
for Windows that could run silently in the background.
The POV-Ray 3.7.0 release proper is the first version of POV-Ray to
which this restriction no longer applies (as it is released under the
AGPL, rather than the proprietary open source license of earlier
versions). So any inclined contributor could now go ahead and develop a
Windows command-line variant of POV-Ray 3.7.
Priorities and manpower of the dev team is currently somewhere else
though, so don't hold your breath for this feature to suddenly appear
out of thin air by magic.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
>
> Kind of, I guess (I've never used it myself, due to a lack of a Mac ;-))
> -- but there's a command-line only version for MacOS.
>
>
> The lack of a command-line only version for Windows is a legacy of acts
> of software piracy, where companies would use POV-Ray as the rendering
> engine in their products without so much as giving any credits, let
> alone informing their users that they could get the render engine for
> free. As a consequence, the copyright owners of POV-Ray had at some time
> decided to effectively forbid the distribution of any POV-Ray version
> for Windows that could run silently in the background.
>
> The POV-Ray 3.7.0 release proper is the first version of POV-Ray to
> which this restriction no longer applies (as it is released under the
> AGPL, rather than the proprietary open source license of earlier
> versions). So any inclined contributor could now go ahead and develop a
> Windows command-line variant of POV-Ray 3.7.
>
> Priorities and manpower of the dev team is currently somewhere else
> though, so don't hold your breath for this feature to suddenly appear
> out of thin air by magic.
Thanks for a detailed explanation!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Mr" <nomail@nomail> wrote:
> clipka <ano### [at] anonymousorg> wrote:
> > Am 29.07.2014 21:24, schrieb LanuHum:
> > > Hellow!
> > > I want to make a render in a shadow mode for a preview of materials in Blender
> > > In Linux - no problem, preview very good
> > > In Windows don't work
> > >
http://blender-3d.ru/forum/index.php?action=dlattach;topic=753.0;attach=2930;image
> >
> > It does tell you what's wrong:
> >
> > "Cannot open INI file 'C:\povray\preview/Preview.ini'."
> >
> > Make sure the file is indeed at that location.
>
> oh, it looks like something is wrong with the slash/backslash\ handling in the
> report. Can you let me know if the last version does work for you?
>
> wheneverpossible using the os.path module methods to concatenate, truncate or
> whatever one has to do with paths makes sure it works more smoothly across
> platforms. possibly one slash should be removed from the hardwritten filename
> and left to be handled by the python's os.path methods, for instance current
> version is:
>
>
> workDir=os.path.dirname(__file__)
> previewDir=os.path.join(workDir, "preview")
>
> ## Make sure Preview directory exists and is empty
> if not os.path.isdir(previewDir):
> os.mkdir(previewDir)
>
> iniPrevFile=os.path.join(previewDir, "Preview.ini")
> inputPrevFile=os.path.join(previewDir, "Preview.pov")
Hi,
The yellow message is still there and Lanuhum architecture is different from
mine, so that I would need to dig into it to understand...
What would you advice I do to adapt the current code? How should we provide a
cross platform path in our pov files? have them use unix path all allong? so
reverse all the windows paths slashes or use unix paths everywhere?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 28.04.2016 um 17:16 schrieb Mr:
> What would you advice I do to adapt the current code? How should we provide a
> cross platform path in our pov files? have them use unix path all allong? so
> reverse all the windows paths slashes or use unix paths everywhere?
For maximum portability, place all files relevant for a scene inside the
very SAME DIRECTORY, and only refer to them by their base filename and
extension.
If you do have compelling reason to spread a scene across multiple
directories, use only RELATIVE PATH NAMES with FORWARD SLASHES as path
separators. The forward slash is the one and only character that is
recognized as a path separator by each and every contemporary official,
semi-official or unofficial version, port or fork of POV-Ray I'm
currently aware of. (*)
Also, when automatically generating scene files and subsequently
invoking POV-Ray to render them, if the scene makes use of library-ish
include files stored someplace else, consider referring to them by their
base filename nonetheless, and instead telling the POV-Ray executable
where to find them by using the +L command-line option. This way you can
keep absolute path names (and usually even relative path names) out of
the scene-specific .ini and .pov files entirely.
(* There's another reason to avoid backslashes as path separators in
POV-Ray scenes or INI files, even if you know your scene will be
rendered by POV-Ray for Windows: The backslash carries special meaning
in string literals as an escape character. Worse yet, versions even as
recent as 3.7.0 included some undocumented inconsistencies in their
backslash handling.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 2016-04-28 12:36, also sprach clipka:
> If you do have compelling reason to spread a scene across multiple
> directories, use only RELATIVE PATH NAMES with FORWARD SLASHES as path
> separators. The forward slash is the one and only character that is
> recognized as a path separator by each and every contemporary official,
> semi-official or unofficial version, port or fork of POV-Ray I'm
> currently aware of. (*)
s/POV-Ray/operating system/
ftfy.
backslashes in paths are evil.
--
dik
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 28.04.2016 um 22:28 schrieb dick balaska:
> Am 2016-04-28 12:36, also sprach clipka:
>
>> If you do have compelling reason to spread a scene across multiple
>> directories, use only RELATIVE PATH NAMES with FORWARD SLASHES as path
>> separators. The forward slash is the one and only character that is
>> recognized as a path separator by each and every contemporary official,
>> semi-official or unofficial version, port or fork of POV-Ray I'm
>> currently aware of. (*)
>
> s/POV-Ray/operating system/
> ftfy.
Not entirely, to my dismay. Most notably, some of the core gizmos of the
Windows command prompt (which I do consider part of the OS) still
stubbornly refuse to recognize forward slashes as path separators.
I guess I really need to learn Powershell programming.
But yeah, backslash-only software has become rare. I guess we can thank
the internet for that.
As for "ftfy": Nope, I didn't misspeak, mistype or whatever. In case of
POV-Ray it's not the OS that decides what characters can be used as path
separators, but POV-Ray itself. Forward slashes would continue to work
perfectly fine in POV-Ray for Windows even if Microsoft suddenly decided
to drop support at the OS level (or so I think; at worst it would be a
matter of changing the compile-time configuration). It should also be
comparatively easy to add support for backslash path separators to the
Unix version (though I don't know why anyone would want to do that).
Conversely, by tampering with the compile-time configuration you could
easily break some functionality of POV-Ray for Windows with regards to
backslash-separated paths.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 2016-04-28 17:37, also sprach clipka:
> some of the core gizmos of the
> Windows command prompt (which I do consider part of the OS) still
> stubbornly refuse to recognize forward slashes as path separators.
Huh, I never considered command.com to be part of the OS.
(But I would say that it is an important part of the OS, which by
definition is part of the OS. My brain is broken.)
Also:
C:\Users\dick>dir "/Users/dick/documents" /w
Volume in drive C is Windows
Volume Serial Number is 30E6-9CD1
Directory of C:\Users\dick\documents
[.]
[..]
audreyad.png
>
> I guess I really need to learn Powershell programming.
Certainly far superior to command.com. Before that existed, I started
with cygwin bash. I have no reason to open a command.com shell.
Windows 10 has Ubuntu bash now. Even less reason to learn powershell. ;)
>
> But yeah, backslash-only software has become rare. I guess we can thank
> the internet for that.
The internet takes full credit for that and demeans you for conceiving
that there could be otherwise. And you're fat (or skinny).
I see backslashes: One of the eclipse/tomcat quick fix hints is to add
C:\\home\\dick\\tomcat\\long\\path
"Argh! Seriously!? I have to change that." -- Living half my life on
Linux, I really refuse to allow \\ in one of my text files.
>
> As for "ftfy": Nope, I didn't misspeak, mistype or whatever.
Sorry. Got it.
I focused on povray and python and calling one from the other and did I
mention I hate backslashes in paths?
Dick from the internet says they're evil.
--
dik
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Hi,
> The yellow message is still there and Lanuhum architecture is different from
> mine, so that I would need to dig into it to understand...
> What would you advice I do to adapt the current code? How should we provide a
> cross platform path in our pov files? have them use unix path all allong? so
> reverse all the windows paths slashes or use unix paths everywhere?
>
>
Never ever use any absolute path anywhere. I've seen to many construct
Absolute paths only work on the original machine.
Place all source files in the same folder/directory and zip or rar that
folder. For all standard includes used, assume that each install of
POV-Ray know how to access them, no mather what OS is used. Don't
include those standard files, it's not needed.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 29.04.2016 um 04:05 schrieb dick balaska:
> Am 2016-04-28 17:37, also sprach clipka:
>> some of the core gizmos of the
>> Windows command prompt (which I do consider part of the OS) still
>> stubbornly refuse to recognize forward slashes as path separators.
>
> Huh, I never considered command.com to be part of the OS.
> (But I would say that it is an important part of the OS, which by
> definition is part of the OS. My brain is broken.)
> Also:
> C:\Users\dick>dir "/Users/dick/documents" /w
> Volume in drive C is Windows
> Volume Serial Number is 30E6-9CD1
>
> Directory of C:\Users\dick\documents
>
> [.]
> [..]
> audreyad.png
Yup. Many cmd.com (not command.com -- that's an entirely outdated DOS
program, not a Windows program) gizmos are perfectly fine with forward
slashes.
But others aren't. Which is why I've made it a habit to avoid
backslashes in batch files like the devil avoids holy water. Which is
why I've even forgotten by now what the stumbling blocks were. Something
very fundamental, that I do recall. Maybe it was the `for` statement, or
the advanced batch parameter evaluation features like `%~n1`. Something
in that ballpark.
>> But yeah, backslash-only software has become rare. I guess we can thank
>> the internet for that.
>
> The internet takes full credit for that and demeans you for conceiving
> that there could be otherwise. And you're fat (or skinny).
General increase in cross-platform data exchange might have been
sufficient to achieve that. But the URL format certainly helped.
And yes, I'm skinny indeed ;)
> I see backslashes: One of the eclipse/tomcat quick fix hints is to add
> C:\\home\\dick\\tomcat\\long\\path
> "Argh! Seriously!? I have to change that." -- Living half my life on
> Linux, I really refuse to allow \\ in one of my text files.
I perfectly agree there.
> and did I mention I hate backslashes in paths?
> Dick from the internet says they're evil.
Dick's right about me being skinny, so who am I to contradict him on
this one.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
