>> Also very interested to see that Ctrl+X does something completely 
>> unexpected and highly catastrophic. Remind me to never, ever press 
>> that while in Blender! o_O
> 
> Actually, it's quite the contrary:  when you're learning, it's best to 
> start from scratch anew everytime you learn something.

I'll say...

> Ctrl+X to me was one of the most useful keycombos in Blender in the 
> beginning.  I wouldn't even save anything (because nothing was worth 
> it), just play around and start anew when anything got wrong or if I 
> thought it was enough learning for a particular technique.

Yeah, that sounds pretty typical. Strange choice of shortcut though.

> It's been changed to a -- perhaps saner -- Ctrl+N(ew) in 2.5 alpha.

OK.

> F1 opens a previous file, F2 saves and ctrl+w writes current changes to 
> the current file.  shift (or alt?) F1 lets you load objects and 
> materials from a previous file into your current file.

Ctrl+W usually closes the current document/application. But in Blender 
it saves? Wacky...

> hope you may have a fair ride...

Yeah...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

nemesis wrote:

> and ctrl+s just saves too.

Oh thank God... :-}

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 escreveu:
>> Ctrl+X to me was one of the most useful keycombos in Blender in the 
>> beginning.  I wouldn't even save anything (because nothing was worth 
>> it), just play around and start anew when anything got wrong or if I 
>> thought it was enough learning for a particular technique.
> 
> Yeah, that sounds pretty typical. Strange choice of shortcut though.

I take it to mean I want to cut current scene to pieces with scissors. :)

> Ctrl+W usually closes the current document/application. But in Blender 
> it saves? Wacky...

Ctrl+W(indow) doesn't quite says much to me, despite what Microsoft 
says.  Ctrl+w(rite) sounds more logical.  Not all editors follow 
Microsoft's conventions, vi comes to mind with :w :)

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

How about this:

  Assume we have a rectangular grid consisting of m vertical lines and n
horizontal lines. All the vertical lines are of equal length and
arranged horizontally, at equal distances from each other. Likewise
all the horizontal lines are of equal length and arranged vertically,
at equal distances from each other. The length of the vertical lines
is the distance between the outermost horizontal lines, and
vice-versa. The two sets of lines is superimposed so that the four
outermost lines coincide at their endpoints, and thus they form a
large rectangle (with all the other lines inside it). No line goes
outside of this rectangle.

  In other words, the grid contains m x n line intersections (and
consequently there are (m-1) x (n-1) small empty rectangles inside the
grid). For example, a standard Go board has a 19 x 19 grid (19
vertical lines and 19 horizontal lines, totaling 361 intersections).

  (While the idea is quite simple, I tried to be as unambiguous as I
could above, which is why the description became somewhat lengthy.)

  Let's define the smallest possible grid to be 2 x 2 (because it's the
smallest that can be formed with lines of non-zero length).

  Such a grid forms many rectangles. A 2 x 2, rather obviously, forms
only one rectangle. However, a 3 x 2 forms 3 rectangles (the two small
rectangles and a third one, which is formed by the outermost lines). A
4 x 2 grid forms 6 rectangles (3 small rectangles, 2 medium-sized and
1 encompassing the whole grid). Likewise a 3 x 3 grid forms 9
rectangles and a 4 x 4 grid forms 36 rectangles. And so on.

  So the task is simple: Write a function f(m,n) which tells how many
rectangles can be found in an m x n grid. (Explain how you came up
with the function).

-- 
                                                          - Warp

Post a reply to this message

No, sir, wait a minute!  You can't propose a new challenge without 
providing an answer to the previous one. :D

Post a reply to this message

Jim Henderson <nos### [at] nospamcom> wrote:
> An assertion that's easy to prove.  Python runs on Macs.  Macs typically 
> have a *1* button mouse.

  Isn't that info a bit old? Does Apple even sell 1-button mice anymore?

  (Apple's mice might *look* like they have only one button, but in reality
they usually have at least four. They can be configured to work as if it had
only one button, though.)

-- 
                                                          - Warp

Post a reply to this message

nemesis <nam### [at] gmailcom> wrote:
> No, sir, wait a minute!  You can't propose a new challenge without 
> providing an answer to the previous one. :D

  The correct answer has already been given several times, even in
graphical form.

-- 
                                                          - Warp

Post a reply to this message

nemesis escreveu:
> Darren New escreveu:
>> nemesis wrote:
>>> right mouse button click (RMB) - selects
>>> left mouse button click (LMB) - changes location of 3D cursor
>>
>> And I think that there pretty much sums up why people think Blender's 
>> interface sucks. :-)
> 
> Heard about that before.  No big deal, though.

and in any case, if Orchid wants to change it, he just needs to grab the 
top bar and pull it down:  the configuration preferences shows up. 
There in the very first tab you have "Select with:" and the options LMB 
or RMB.

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

nemesis wrote:

> navigating through 3D space:
> numeric keyboard:
> 1 - front view
> 7 - top view
> 3 - side view

This seemed like a pretty weird choice, until I noticed the position of 
these keys on the keypad.

Also... Blender seems to incorrectly assume that Z is "up" and Y is 
"back". (It should obviously be the other way around.)

> with the mouse:
> alt+LMB - rotate the scene around by moving the mouse

Well, at least it works.

> now, here's a first lesson to you:
> 
> 1) ctrl+x to create a new scene
> 
> 2) cube is already selected so tab to enter mesh edit mode
> 
> 3) input this:  s (scale) y (restricted to y axis) then move the mouse 
> until its reasonably thin in y axis

Interesting how the amount of scaling is apparently completely unrelated 
to the mouse movement... (Seems to scale the cube by about 20% of the 
distance the mouse is moved.)

> 4) a to deselect all
> 
> 5) ctrl+tab and select face mode
> 
> 6) ctrl+space and select "Enable/Disable" so it doesn't get in the way
> 
> 7) select the right face  (you may zoom in a bit to make it clearer)
> 
> 8) alt+shift(+Windows)+LMB and drag the cube to the left corner of the 
> screen
> 
> 9) ok, right face selected all you do now is extrude it in the xy plane 
> with ctrl+LMB clicks.
> 
> You may trace it along funky paths in the xy plane (as default view is 
> top view in the z axis) as long as the steps are about same length as 
> the original cube.

OK, this one took me a while to figure out. You'd think you extrude it 
by dragging the face that you want to extrude... but no. You just click 
and Blender places faces at random for you.

> now:
> 
> 10) tab to exit mesh edit mode
> 
> 11) F9 -> Modifiers panel down there -> Add Modifier -> Level 3

F9 doesn't appear to do anything. However, I did manage to find the 
command, and it did turn the tangled mess of polygons into... a rather 
liquid-looking mess of smaller polygons.

> 12) In the Link and Materials panel to the left, click Set Smooth down 
> there.

Now with fake light smoothing. (If it weren't for the 
self-intersections, it might even look like a real curved surface...)

> 13) in the numeric numeric keypad, hit 5 to enter perspective mode (5 
> again to go back to orthographic)
> 
> 14) drag your scene around with alt+shift+LMB, zoom with mouse wheel and 
> rotate with alt+shift+LMB to get the "belt" centered on screen
> 
> 15) once you're satisfied with it, hit ctrl+alt+0 to get the camera set 
> in this position
> 
> 16) F8 -> World ajust the default black blue sky to a color of your liking
> 
> 17) in the panel just next to it, click on the Amb Occ tab and turn on 
> Ambient Occlusion (default settings ok)
> 
> 18) hit F12 to render with default settings

One very, very, VERY grainy grey image...

Oh, wait, I think the light source might be on the other side... Yeah, 
OK, that looks a bit better. Still horrifyingly blocky, but at least 
with some specular hilights now.


-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On Wed, 16 Dec 2009 16:33:45 -0500, Warp wrote:

> Jim Henderson <nos### [at] nospamcom> wrote:
>> An assertion that's easy to prove.  Python runs on Macs.  Macs
>> typically have a *1* button mouse.
> 
>   Isn't that info a bit old? Does Apple even sell 1-button mice anymore?
> 
>   (Apple's mice might *look* like they have only one button, but in
>   reality
> they usually have at least four. They can be configured to work as if it
> had only one button, though.)

Perhaps, I'm not a Mac user.  But I reckon that Python was around before 
Apple switched to a multi-button mouse.

Jim

Post a reply to this message