[Bf-cycles] My Blender 2.67 keeps coing into "line select" Mode when I am in "Vertex sleect", and I am needing to stay in vertex select. Is there a fix or a setting? and how do I stop the zoom from jumping in increments and soom in up close with out the object being out of frame? Thanks

Mon Jul 15 22:37:13 CEST 2013

----- Original Message -----
From: bf-cycles-request at blender.org
To: bf-cycles at blender.org
Sent: Sat, 13 Jul 2013 06:00:06 -0400 (EDT)
Subject: Bf-cycles Digest, Vol 27, Issue 7

Send Bf-cycles mailing list submissions to
	bf-cycles at blender.org

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.blender.org/mailman/listinfo/bf-cycles
or, via email, send a message with subject or body 'help' to
	bf-cycles-request at blender.org

You can reach the person managing the list at
	bf-cycles-owner at blender.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Bf-cycles digest..."

Today's Topics:

   1. Cycles geometry synchronization (Matthew Heimlich)
   2. Re: Cycles geometry synchronization (Brecht Van Lommel)
   3. Re: Cycles geometry synchronization (Matthew Heimlich)
   4. Re: Cycles geometry synchronization (Brecht Van Lommel)

----------------------------------------------------------------------

Message: 1
Date: Fri, 12 Jul 2013 18:50:53 -0400
From: Matthew Heimlich <matt.heimlich at gmail.com>
Subject: [Bf-cycles] Cycles geometry synchronization
To: bf-cycles at blender.org
Message-ID:
	<CAPBuH4ZjAPAnLD3+diynPmx=-sC8VOLwTNDAWqh26bQkyYDXOA at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Hey all,

I was thinking about the long sync step when rendering with Cycles and had
a couple of questions. As far as I can tell, external renderers in other 3D
packages done require this step. Is this because the other
renderers/packages directly use the geometry data already in memory
directly from the 3D package? If so, this makes me wonder if this step is a
due to a limitation of Cycles not being as deeply integrated with Blender
as it could be (if I recall it was originally intended to operate as a
standalone that could work with other packages as well) or if there is a
limitation with Blender itself in terms of the data it makes available to
external programs.

As I understand it, the process now is:

Start rendering process ->
Copy geometry data from Blender to a Cycles buffer ->
Build BVH based on this data ->
Begin intersection tests

With the geometry copy being a very time consuming step, especially for
complex scenes. Please correct me if I'm wrong anywhere. Just trying to
continue wrapping my head around the inner workings of Cycles as a whole.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20130712/80cc1484/attachment-0001.htm 

------------------------------

Message: 2
Date: Sat, 13 Jul 2013 01:13:27 +0200
From: Brecht Van Lommel <brechtvanlommel at pandora.be>
Subject: Re: [Bf-cycles] Cycles geometry synchronization
To: bf-cycles at blender.org
Message-ID:
	<CAKFUgC13=wThV64Pd4chsNkMZBGBDprqRnCs5JydgmF=b2Ha2g at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Most of the time is usually evaluating modifiers, particularly for
subdivision surfaces or particles. Once Blender has evaluated those
things the copying itself isn't that slow from what I've analyzed, and
I'm sure other render engines have similar steps, just under a
different name?

What we could optimize here is doing multithreaded sync(this relies on
the multithreaded depsgraph project), or doing our own subdivision in
Cycles. If it's particularly slow without modifiers that would be
interesting to investigate and see how it could be made faster.

It doesn't have anything to do with how deeply Cycles is integrated
really, just stuff that could be worked on.

On Sat, Jul 13, 2013 at 12:50 AM, Matthew Heimlich
<matt.heimlich at gmail.com> wrote:
> Hey all,
>
> I was thinking about the long sync step when rendering with Cycles and had a
> couple of questions. As far as I can tell, external renderers in other 3D
> packages done require this step. Is this because the other
> renderers/packages directly use the geometry data already in memory directly
> from the 3D package? If so, this makes me wonder if this step is a due to a
> limitation of Cycles not being as deeply integrated with Blender as it could
> be (if I recall it was originally intended to operate as a standalone that
> could work with other packages as well) or if there is a limitation with
> Blender itself in terms of the data it makes available to external programs.
>
> As I understand it, the process now is:
>
> Start rendering process ->
> Copy geometry data from Blender to a Cycles buffer ->
> Build BVH based on this data ->
> Begin intersection tests
>
> With the geometry copy being a very time consuming step, especially for
> complex scenes. Please correct me if I'm wrong anywhere. Just trying to
> continue wrapping my head around the inner workings of Cycles as a whole.
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles
>

------------------------------

Message: 3
Date: Fri, 12 Jul 2013 19:35:30 -0400
From: Matthew Heimlich <matt.heimlich at gmail.com>
Subject: Re: [Bf-cycles] Cycles geometry synchronization
To: bf-cycles at blender.org
Message-ID:
	<CAPBuH4aMC0MYW30r2-9p2jhY_wQ0kOgJkRB=cAiySvMBXRdQgA at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

I've waited up to 10 minutes for synchronization for a single model before,
going from SubD level 1 in the viewport to SubD level 4 for rendering (3
million polys or so). Not sure where the optimizations are in the other
packages, but rendering begins pretty much immediately for them. Not a
negative criticism of Cycles by any means, I'm just wondering where in the
pre-render process optimizations could be made to increase interactivity.

Another question I've had is if there are any plans to do some kind of
cache to memory so that a scene doesn't need to be re-synced and rebuilt
for each frame when f12 rendering if nothing has changed. In a turntable I
did of a character not long ago, sync and BVH building accounted for nearly
50% of the total render time despite the camera being the only thing
animated in the scene.

On Fri, Jul 12, 2013 at 7:13 PM, Brecht Van Lommel <
brechtvanlommel at pandora.be> wrote:

> Most of the time is usually evaluating modifiers, particularly for
> subdivision surfaces or particles. Once Blender has evaluated those
> things the copying itself isn't that slow from what I've analyzed, and
> I'm sure other render engines have similar steps, just under a
> different name?
>
> What we could optimize here is doing multithreaded sync(this relies on
> the multithreaded depsgraph project), or doing our own subdivision in
> Cycles. If it's particularly slow without modifiers that would be
> interesting to investigate and see how it could be made faster.
>
> It doesn't have anything to do with how deeply Cycles is integrated
> really, just stuff that could be worked on.
>
> On Sat, Jul 13, 2013 at 12:50 AM, Matthew Heimlich
> <matt.heimlich at gmail.com> wrote:
> > Hey all,
> >
> > I was thinking about the long sync step when rendering with Cycles and
> had a
> > couple of questions. As far as I can tell, external renderers in other 3D
> > packages done require this step. Is this because the other
> > renderers/packages directly use the geometry data already in memory
> directly
> > from the 3D package? If so, this makes me wonder if this step is a due
> to a
> > limitation of Cycles not being as deeply integrated with Blender as it
> could
> > be (if I recall it was originally intended to operate as a standalone
> that
> > could work with other packages as well) or if there is a limitation with
> > Blender itself in terms of the data it makes available to external
> programs.
> >
> > As I understand it, the process now is:
> >
> > Start rendering process ->
> > Copy geometry data from Blender to a Cycles buffer ->
> > Build BVH based on this data ->
> > Begin intersection tests
> >
> > With the geometry copy being a very time consuming step, especially for
> > complex scenes. Please correct me if I'm wrong anywhere. Just trying to
> > continue wrapping my head around the inner workings of Cycles as a whole.
> >
> > _______________________________________________
> > Bf-cycles mailing list
> > Bf-cycles at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-cycles
> >
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20130712/96997f80/attachment-0001.htm 

------------------------------

Message: 4
Date: Sat, 13 Jul 2013 02:47:40 +0200
From: Brecht Van Lommel <brechtvanlommel at pandora.be>
Subject: Re: [Bf-cycles] Cycles geometry synchronization
To: bf-cycles at blender.org
Message-ID:
	<CAKFUgC278kOWKp0wdHpNdt3UFnZNFH66orp3j6tvAvWX74r8wQ at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

A scene with 3 million polygons should never take 10 minutes, that
sounds like a bug. Some sort of cache would be useful but at the
moment is somewhat difficult to implement, we don't have a way to
track what changes between renders. But the first thing to do is
really to optimize export if there are cases where it takes this long,
that's not normal.

On Sat, Jul 13, 2013 at 1:35 AM, Matthew Heimlich
<matt.heimlich at gmail.com> wrote:
> I've waited up to 10 minutes for synchronization for a single model before,
> going from SubD level 1 in the viewport to SubD level 4 for rendering (3
> million polys or so). Not sure where the optimizations are in the other
> packages, but rendering begins pretty much immediately for them. Not a
> negative criticism of Cycles by any means, I'm just wondering where in the
> pre-render process optimizations could be made to increase interactivity.
>
> Another question I've had is if there are any plans to do some kind of cache
> to memory so that a scene doesn't need to be re-synced and rebuilt for each
> frame when f12 rendering if nothing has changed. In a turntable I did of a
> character not long ago, sync and BVH building accounted for nearly 50% of
> the total render time despite the camera being the only thing animated in
> the scene.
>
>
> On Fri, Jul 12, 2013 at 7:13 PM, Brecht Van Lommel
> <brechtvanlommel at pandora.be> wrote:
>>
>> Most of the time is usually evaluating modifiers, particularly for
>> subdivision surfaces or particles. Once Blender has evaluated those
>> things the copying itself isn't that slow from what I've analyzed, and
>> I'm sure other render engines have similar steps, just under a
>> different name?
>>
>> What we could optimize here is doing multithreaded sync(this relies on
>> the multithreaded depsgraph project), or doing our own subdivision in
>> Cycles. If it's particularly slow without modifiers that would be
>> interesting to investigate and see how it could be made faster.
>>
>> It doesn't have anything to do with how deeply Cycles is integrated
>> really, just stuff that could be worked on.
>>
>> On Sat, Jul 13, 2013 at 12:50 AM, Matthew Heimlich
>> <matt.heimlich at gmail.com> wrote:
>> > Hey all,
>> >
>> > I was thinking about the long sync step when rendering with Cycles and
>> > had a
>> > couple of questions. As far as I can tell, external renderers in other
>> > 3D
>> > packages done require this step. Is this because the other
>> > renderers/packages directly use the geometry data already in memory
>> > directly
>> > from the 3D package? If so, this makes me wonder if this step is a due
>> > to a
>> > limitation of Cycles not being as deeply integrated with Blender as it
>> > could
>> > be (if I recall it was originally intended to operate as a standalone
>> > that
>> > could work with other packages as well) or if there is a limitation with
>> > Blender itself in terms of the data it makes available to external
>> > programs.
>> >
>> > As I understand it, the process now is:
>> >
>> > Start rendering process ->
>> > Copy geometry data from Blender to a Cycles buffer ->
>> > Build BVH based on this data ->
>> > Begin intersection tests
>> >
>> > With the geometry copy being a very time consuming step, especially for
>> > complex scenes. Please correct me if I'm wrong anywhere. Just trying to
>> > continue wrapping my head around the inner workings of Cycles as a
>> > whole.
>> >
>> > _______________________________________________
>> > Bf-cycles mailing list
>> > Bf-cycles at blender.org
>> > http://lists.blender.org/mailman/listinfo/bf-cycles
>> >
>> _______________________________________________
>> Bf-cycles mailing list
>> Bf-cycles at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-cycles
>
>
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles
>

------------------------------

_______________________________________________
Bf-cycles mailing list
Bf-cycles at blender.org
http://lists.blender.org/mailman/listinfo/bf-cycles

End of Bf-cycles Digest, Vol 27, Issue 7
****************************************