POV-Ray : Newsgroups : povray.tools.general : VR Brainstorming Server Time
29 Mar 2024 10:29:09 EDT (-0400)
  VR Brainstorming (Message 4 to 13 of 13)  
<<< Previous 3 Messages Goto Initial 10 Messages
From: Stephen
Subject: Re: VR Brainstorming
Date: 14 Sep 2014 08:42:19
Message: <54158d2b@news.povray.org>
On 13/09/2014 23:51, clipka wrote:
> Am 13.09.2014 23:38, schrieb Stephen:

>> Are you sure? Bishop3D can import a subset of SDL and display it in
>> OpenGl. No I'm not asking you to write a parser as I've read the answer
>> a thousand times. :-(
>> Just a thought.
>
> Well, OpenGL does need a mesh representation of the scene, so yes, I'm
> sure about this statement ;-)
>

I did not know that. You have boggled my mind.

> Whether the conversion process would be render-ish or parse-ish is an
> entirely different question.
>

I'm out of my depth here.

>
> As for the parser: We already have one - it's part of POV-Ray.
>

That I knew. :-)

> Ideally, we'd have a proper clear-cut C++ API for the representation of
> a scene (at present the internal representation /still/ partially C-ish
> and poorly delineated), and the parser would be just one module using
> this API to generate such a scene. Add to that a feature in the API to
> get a mesh representation from any arbitrary shape, and we'd have the
> best core for a POV-Ray SDL import filter one could ever wish for.
>

I like the sound of that.

> As a matter of fact this is the direction the dev team intends to go, in
> order to make it easier to integrate components of POV-Ray into other
> pieces of software - be it as an input filter or a render engine. But it
> won't happen overnight, and I won't be the only one working towards this
> goal.
>
Are we thinking about Pov 4.0?
It all sounds good

>
>>> Unfortunately I have only a rather basic understanding of how a
>>> real-world lathe is used in practice, and have never gotten my hands on
>>> one myself, but I know there are various "handicrafters" among you
>>> people, who certainly have plenty of experience in this area, so I'd
>>> appreciate any input especially from you guys.
>>>
>> It is basically a SOR.
>
> Thanks, my basic understanding of a real-world lathe does cover /that/
> fact ;-)
>

I knew I should have put a smiley there.

> I've even heard tell that it is typically used with sharp tools to
> remove parts of the material. :-)
>
And abrasive ones for Anti-Aliasing.

Think wood turning, it is simpler and more "hands on".
I've never used a lathe myself but I've stood beside people who were 
using them and watched.

In the virtual world you could have an object spinning in mid air to be 
turned (shaped). So to add verisimilitude the left hand side (LHS) will 
have a spindle or a chuck that holds the wood and rotates it. The 
spindle is set into bearings called a headstock. This is driven either 
by a motor or a foot treadle. The RHS of the wood is kept in place using 
what is called a Tailstock.
(At this point I thought that if you could have haptic feedback a 
virtual potters wheel might be simpler. Less parts.)
Or if you are turning a bowl no Tailstock.
You need a toolrest to support the cutting tool.
That is it in its simplest form.

See if these help
http://www.woodworking.co.uk/Technical/Beginners/beginners.html#Lathe

http://www.getwoodworking.com/news/article/turning-for-beginners-part-1/885



-- 

Regards
     Stephen


Post a reply to this message

From: Bald Eagle
Subject: Re: VR Brainstorming
Date: 14 Sep 2014 09:40:01
Message: <web.54159a25a15068255e7df57c0@news.povray.org>
Usually woodlathes are used with a variety of fairly large tools (leverage) and
you work your way from the rough-turning of an octagonally cut workpiece into a
cylindrical one, then medium turning to get the countour/profile that you want,
and then some finer tools that you actually use to sort of slice or peel to get
a very fine finish.

Big industrial ones, like the ones used to make baseball bats or other
high-throughput items use a copying template and really go FAST.
See youtube for "How It's Made"

Metal lathes have the cutter mounted in a carriage that you either move with
screws/gears and a wheel, or by motor-driven means for things like cutting screw
threads.  Different speeds are used to account for things like heat, chatter,
chipping, etc. that are peculiar to the turning and feeding speed coupled with
the type and hardness of the metal you're cutting.
There are also specialized tools like "knurling wheels" that actually press a
texture into the surface of the metal rather than cut the pattern into it.

I'd say youtube is your friend, or if you want an actual lathe manual, I might
be able to dig you up a pdf ...


Post a reply to this message

From: clipka
Subject: Re: VR Brainstorming
Date: 14 Sep 2014 11:20:55
Message: <5415b257$1@news.povray.org>
Am 14.09.2014 14:42, schrieb Stephen:

>> Whether the conversion process would be render-ish or parse-ish is an
>> entirely different question.
>
> I'm out of my depth here.

A mesh representation of the scene would probably be easiest to achieve 
by parsing the scene, then having dedicated code convert each and every 
object separately into a mesh.

A voxel ("volume pixel", i.e. 3D array of boxes) representation of the 
scene could be generated in a similar way; it could, however, also be 
generated by having POV-Ray parse the scene, and then use existing code 
in the render engine to systematically ray-trace it, collecting not only 
colour information but also the intersection position information.

>> As a matter of fact this is the direction the dev team intends to go, in
>> order to make it easier to integrate components of POV-Ray into other
>> pieces of software - be it as an input filter or a render engine. But it
>> won't happen overnight, and I won't be the only one working towards this
>> goal.
>>
> Are we thinking about Pov 4.0?

Not exactly; more like POV-Ray 3.8 and 3.9, as POV-Ray 4.0 will most 
probably be the step that introduces a brand new parser with a brand new 
syntax. That'll obviously be easier to implement once we already have a 
clear-cut API for the render engine.

>> I've even heard tell that it is typically used with sharp tools to
>> remove parts of the material. :-)
>>
> And abrasive ones for Anti-Aliasing.

*ROTFLMAO!*

> Think wood turning, it is simpler and more "hands on".

Well, the primary tool used for that /is/ a lathe, isn't it?

Actually that's the thing I'm primarily thinking of - certainly not a 
CNC metal-machining lathe, that would be boring (uh... no pun intended).


Post a reply to this message

From: clipka
Subject: Re: VR Brainstorming
Date: 14 Sep 2014 11:25:46
Message: <5415b37a$1@news.povray.org>
Am 14.09.2014 15:37, schrieb Bald Eagle:
> Usually woodlathes are used with a variety of fairly large tools (leverage) and
> you work your way from the rough-turning of an octagonally cut workpiece into a
> cylindrical one, then medium turning to get the countour/profile that you want,
> and then some finer tools that you actually use to sort of slice or peel to get
> a very fine finish.

I think I'd want the user to start with a square or rectangular cut 
workpiece, allowing them to leave some part of the item in that shape. 
Output to POV-Ray would then of course be an intersection of a box and a 
lathe object.


Post a reply to this message

From: Stephen
Subject: Re: VR Brainstorming
Date: 14 Sep 2014 13:25:28
Message: <5415cf88$1@news.povray.org>
On 14/09/2014 16:20, clipka wrote:
> Am 14.09.2014 14:42, schrieb Stephen:
>
>>> Whether the conversion process would be render-ish or parse-ish is an
>>> entirely different question.
>>
>> I'm out of my depth here.
>
> A mesh representation of the scene would probably be easiest to achieve
> by parsing the scene, then having dedicated code convert each and every
> object separately into a mesh.
>

Not using the tessellation that can be done in SDL, then?

> A voxel ("volume pixel", i.e. 3D array of boxes) representation of the
> scene could be generated in a similar way; it could, however, also be
> generated by having POV-Ray parse the scene, and then use existing code
> in the render engine to systematically ray-trace it, collecting not only
> colour information but also the intersection position information.
>

How would that handle parts that are obscured by itself or other objects?

>>> As a matter of fact this is the direction the dev team intends to go, in
>>> order to make it easier to integrate components of POV-Ray into other
>>> pieces of software - be it as an input filter or a render engine. But it
>>> won't happen overnight, and I won't be the only one working towards this
>>> goal.
>>>
>> Are we thinking about Pov 4.0?
>
> Not exactly; more like POV-Ray 3.8 and 3.9, as POV-Ray 4.0 will most
> probably be the step that introduces a brand new parser with a brand new
> syntax. That'll obviously be easier to implement once we already have a
> clear-cut API for the render engine.
>

Interesting, thanks for explaining in a way I can understand.

>>> I've even heard tell that it is typically used with sharp tools to
>>> remove parts of the material. :-)
>>>
>> And abrasive ones for Anti-Aliasing.
>
> *ROTFLMAO!*
>

We are here to serve. :-)

>> Think wood turning, it is simpler and more "hands on".
>
> Well, the primary tool used for that /is/ a lathe, isn't it?
>

Yes of course. A lathe is a turning machine.

> Actually that's the thing I'm primarily thinking of - certainly not a
> CNC metal-machining lathe, that would be boring (uh... no pun intended).
>

You know the drill. ;-)

A manual metal turning lathe would be over complicated IMO.
And where is the fun in pushing a button to get your shape.
Have you thought about the Kinect as an i/p device?


-- 

Regards
     Stephen


Post a reply to this message

From: clipka
Subject: Re: VR Brainstorming
Date: 15 Sep 2014 14:35:12
Message: <54173160$1@news.povray.org>
Am 14.09.2014 19:25, schrieb Stephen:
> On 14/09/2014 16:20, clipka wrote:
>> Am 14.09.2014 14:42, schrieb Stephen:
>>
>>>> Whether the conversion process would be render-ish or parse-ish is an
>>>> entirely different question.
>>>
>>> I'm out of my depth here.
>>
>> A mesh representation of the scene would probably be easiest to achieve
>> by parsing the scene, then having dedicated code convert each and every
>> object separately into a mesh.
>
> Not using the tessellation that can be done in SDL, then?

The underlying algorithm may be the same for certain objects (most 
notably isosurfaces), but no - tesselation in SDL is a tad too slow for 
my taste ;-)

Besides, IIRC Jerome has already included some inbuilt tesselation 
features in his fork - still need to steal his code and put it into 
UberPOV...

>> A voxel ("volume pixel", i.e. 3D array of boxes) representation of the
>> scene could be generated in a similar way; it could, however, also be
>> generated by having POV-Ray parse the scene, and then use existing code
>> in the render engine to systematically ray-trace it, collecting not only
>> colour information but also the intersection position information.
>>
>
> How would that handle parts that are obscured by itself or other objects?

It would have to trace from different locations.

Maybe something like, you will initially see only the parts visible from 
the initial camera position, but tracing continues as you move your head 
about, and the missing pieces will be filled in over time, maybe with 
gradually increasing detail.

> A manual metal turning lathe would be over complicated IMO.
> And where is the fun in pushing a button to get your shape.
> Have you thought about the Kinect as an i/p device?

The idea briefly crossed my mind, but not long enough to be examined in 
any noteworthy detail. Might be a way to go - but then I'd need to 
obtain a Kinect as well, and fight my way through its API in addition to 
the Oculus Rift's. So, bottom line: Kinect input will most certainly not 
feature in the initial version. I might re-visit the idea once the 
Oculus Rift part and the game controller input are flying.


Post a reply to this message

From: Stephen
Subject: Re: VR Brainstorming
Date: 16 Sep 2014 10:55:53
Message: <54184f79$1@news.povray.org>
On 15/09/2014 19:34, clipka wrote:
>> How would that handle parts that are obscured by itself or other objects?
>
> It would have to trace from different locations.
>
> Maybe something like, you will initially see only the parts visible from
> the initial camera position, but tracing continues as you move your head
> about, and the missing pieces will be filled in over time, maybe with
> gradually increasing detail.
>

Real time rendering?
Is that using the feature from Beta 17?

>> A manual metal turning lathe would be over complicated IMO.
>> And where is the fun in pushing a button to get your shape.
>> Have you thought about the Kinect as an i/p device?
>
> The idea briefly crossed my mind, but not long enough to be examined in
> any noteworthy detail. Might be a way to go - but then I'd need to
> obtain a Kinect as well, and fight my way through its API in addition to
> the Oculus Rift's. So, bottom line: Kinect input will most certainly not
> feature in the initial version. I might re-visit the idea once the
> Oculus Rift part and the game controller input are flying.

Fairy Nuff. :-)

-- 

Regards
     Stephen


Post a reply to this message

From: clipka
Subject: Re: VR Brainstorming
Date: 16 Sep 2014 14:42:11
Message: <54188483@news.povray.org>
Am 16.09.2014 16:55, schrieb Stephen:
> On 15/09/2014 19:34, clipka wrote:
>>> How would that handle parts that are obscured by itself or other
>>> objects?
>>
>> It would have to trace from different locations.
>>
>> Maybe something like, you will initially see only the parts visible from
>> the initial camera position, but tracing continues as you move your head
>> about, and the missing pieces will be filled in over time, maybe with
>> gradually increasing detail.
>>
>
> Real time rendering?
> Is that using the feature from Beta 17?

No, certainly not; that seems to have been a rather specified 
experimental thing.


Post a reply to this message

From: clipka
Subject: Re: VR Brainstorming
Date: 23 Sep 2014 02:13:30
Message: <54210f8a@news.povray.org>
Am 14.09.2014 19:25, schrieb Stephen:

> Have you thought about the Kinect as an i/p device?

Just found this on the net (via the Elite forums):

http://www.pcmag.com/article2/0,2817,2465498,00.asp


Post a reply to this message

From: Stephen
Subject: Re: VR Brainstorming
Date: 23 Sep 2014 04:14:14
Message: <54212bd6$1@news.povray.org>
On 23/09/2014 07:13, clipka wrote:
> Am 14.09.2014 19:25, schrieb Stephen:
>
>> Have you thought about the Kinect as an i/p device?
>
> Just found this on the net (via the Elite forums):
>
> http://www.pcmag.com/article2/0,2817,2465498,00.asp
>

It looks like it would do the trick. :-)

-- 

Regards
     Stephen


Post a reply to this message

<<< Previous 3 Messages Goto Initial 10 Messages

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