[realXtend] Naali 0.3.2 released

2010-10-11 Thread Antti Ilomäki
New version of Naali is available.

Note that the 0.1.4 Taiga or newer is required for the scene upload
functionality to work properly. In addition to important bug fixes,
Naali 0.3.2 has new avatar editor functionality, better camera
controls and the internals have been reworked. The Mac version is
still under construction, we hope to have it available soon.

You can download the latest Naali here:
http://code.google.com/p/realxtend-naali/downloads/detail?name=Naali-0.3.2.execan=2q=

-- 
http://groups.google.com/group/realxtend
http://www.realxtend.org


Re: [realXtend] Suggestion: WikiTree support

2010-10-11 Thread Antti Ilomäki
Arise, ancient thread!

Wiki-Tree looks quite interesting. I think Jon Brouchoud has read this
list at some point, perhaps he could enlighten us a little? I wonder
how much of the WikiTree stuff would work directly on top of Taiga /
Naali, any guesses to how much work the porting would be?

2010/6/2 Peter Quirk peter_qu...@hotmail.com:
 I'd like to see something like the WikiTree [http://sourceforge.net/
 projects/wikitree3d/] (with Naali/Taiga extensions) included in the
 base distribution. Making it easier for people to build, create
 checkpoints, revert to a previous design, etc. would be really
 helpful.

 --
 http://groups.google.com/group/realxtend
 http://www.realxtend.org

-- 
http://groups.google.com/group/realxtend
http://www.realxtend.org


[realXtend] Talking about 3D animations

2010-10-11 Thread Gustavo Alberto Navarro Bilbao
Hi to all:

Videotutorial (in spanish) here:

*Tecnologias3D segunda parte*
http://vimeo.com/15712634

Best R.

Alberto

-- 
http://groups.google.com/group/realxtend
http://www.realxtend.org

Re: [realXtend] Re: Uploading Scene in Naali 0.3.2 Taiga 0.1.4

2010-10-11 Thread Toni Alatalo
On su, 2010-10-10 at 13:09 +0200, Peter Steinlechner wrote:
 thanks for your reply, I had it run for about a half hour without any
 results. Also when I try to load Albertos sample scene, it doesn't
 show up local. But if I use my test scenes which have smaller mesh
 size, they show up local. I'm affraid it must be something related to
 the Win7 installation I have, as Albertos scene seems to run perfectly
 on his XP installation. About the zip file you mentioned, where should
 I look for it? I checked in the same folder where the scene files are.

Yes it seems to make the zip in the same folder. I think that it gets
stuck for you at 14% and you don't see .zip files there mean that the
zip creation fails somehow. Unfortunately I think the errors from there
are not going to the log nor f1 console now, only to the console window
which is disabled in releases .. we have to fix that too.

That worked for me with both of your test scenes, they both show locally
and Naali makes the zips, but so far have managed to publish only the
other to the server 'cause am encountering some other prob with my
server setup perhaps.

Alberto's EDIFICIO 6 gives me a parser error when reading the file
locally. I suspect a bug / incompatibility in the simple dotscene loader
from the python-ogre project. Are you saying that worked for you? Or did
I find a different scene zip than the one you meant.

Matti already did some fixes and little ui improvements today, we'll be
testing more.

 Pedro

~Toni

 On Sun, Oct 10, 2010 at 8:47 AM, Toni Alatalo ant...@kyperjokki.fi
 wrote:
 On su, 2010-10-10 at 09:42 +0300, Toni Alatalo wrote:
  On la, 2010-10-09 at 15:29 +0200, Peter Steinlechner wrote:
   Have you tried also to export the scene without the camera
 and the
   lamp ? I just selected the objects and it worked well.
  That won't affect the zip making + uploading part. If you
 can see the
  scene locally after the load, it could be read ok. The
 publish button
  just blindly makes a zip of the files and uploads it using
 http.
 
 
 Oops sorry apparently I was wrong there -- the publisher
 actually does
 read the scene structure to find material references etc., I
 guess to
 know what textures etc. it needs to put in the zip, so it is
 indeed
 possible there is some bug there if it doesn't take into
 regard entities
 without mats like cameras. So this may be worth a try too.
 
 ~Toni
 
 
  The people who had problems: did you wait for long?
 
  The fact that the GUI status bar now gets stuck does not
 mean that he
  tool got stuck. It just is not yet implemented so that it
 would update
  incrementally -- it jumps in big steps when everything is
 done, so the
  GUI is misleading.
 
  I read the publish code now, and the zip making part
 apparently copies
  all the textures to a temporary directory etc. which can
 take a while.
 
  This is probably made worse by that zip making being run in
 a thread in
  the same process. So if you have Naali running at
 not-ultra-high fps, it
  can be slow (Naali eats all cpu of that processor, and if
 you are on
  multicore, the other processors are not utilized for the zip
 making now
  because cpython has a global lock).
 
  So if the people who had probs can please test again, let it
 run for a
  long time, and see if a .zip file finally appears etc. that
 would be
  helpful.
 
  On the dev side I think we should port that to use a
 subprocess -- then
  it will not be slowed down by Naali mainloop with the
 rendering etc.,
  especially on multicore machines should be normal speed for
 zip making
  then. Matti R. can see an example in pychessview if wants to
 give this a
  shot. Fortunately it should be trivial, perhaps only
 1-2hours of work to
  adapt. I may try it next week if have time, can give an
 update then if
  it works out.
 
  Thanks for the feedback!
 
  ~Toni
 
   On Sat, Oct 9, 2010 at 3:01 PM, MasterJ
 djmat...@hotmail.com wrote:
   here i have same trouble too (and more becaue i
 have a python
   error
   with blender)
   the progress bar stop at 14%.
   but i use Naali 0.3.1 and Taiga 0.1.4
  
   i have changed nothing on the opensim.ini here.
   and i never try uplaod scene from console because
 i can't
   found the
 

Re: [realXtend] Re: Uploading Scene in Naali 0.3.2 Taiga 0.1.4

2010-10-11 Thread Peter Steinlechner
Hi Toni - thanks for the news, I was using the Edificio6 scene that Alberto
had posted here in the group. So I think we both are using the same. I
forgot to mention, that I used for this test a Taiga 0.1.4 and a Taiga 0.2.0
RC1 setup - both freshly installed. I don't know if that helps you, but when
in local scene I choose the Save option, a file with the scene name and the
ending .saved is created in the scene directory on the local PC. As for the
zip file that should be created, I can confirm that they don't get created
on my PC. To create the scenes I used Blender 2.49b with the ogre mesh and
scene exporter found on the ogre site.

On Mon, Oct 11, 2010 at 3:59 PM, Toni Alatalo ant...@kyperjokki.fi wrote:

 On su, 2010-10-10 at 13:09 +0200, Peter Steinlechner wrote:
  thanks for your reply, I had it run for about a half hour without any
  results. Also when I try to load Albertos sample scene, it doesn't
  show up local. But if I use my test scenes which have smaller mesh
  size, they show up local. I'm affraid it must be something related to
  the Win7 installation I have, as Albertos scene seems to run perfectly
  on his XP installation. About the zip file you mentioned, where should
  I look for it? I checked in the same folder where the scene files are.

 Yes it seems to make the zip in the same folder. I think that it gets
 stuck for you at 14% and you don't see .zip files there mean that the
 zip creation fails somehow. Unfortunately I think the errors from there
 are not going to the log nor f1 console now, only to the console window
 which is disabled in releases .. we have to fix that too.

 That worked for me with both of your test scenes, they both show locally
 and Naali makes the zips, but so far have managed to publish only the
 other to the server 'cause am encountering some other prob with my
 server setup perhaps.

 Alberto's EDIFICIO 6 gives me a parser error when reading the file
 locally. I suspect a bug / incompatibility in the simple dotscene loader
 from the python-ogre project. Are you saying that worked for you? Or did
 I find a different scene zip than the one you meant.

 Matti already did some fixes and little ui improvements today, we'll be
 testing more.

  Pedro

 ~Toni

  On Sun, Oct 10, 2010 at 8:47 AM, Toni Alatalo ant...@kyperjokki.fi
  wrote:
  On su, 2010-10-10 at 09:42 +0300, Toni Alatalo wrote:
   On la, 2010-10-09 at 15:29 +0200, Peter Steinlechner wrote:
Have you tried also to export the scene without the camera
  and the
lamp ? I just selected the objects and it worked well.
   That won't affect the zip making + uploading part. If you
  can see the
   scene locally after the load, it could be read ok. The
  publish button
   just blindly makes a zip of the files and uploads it using
  http.
 
 
  Oops sorry apparently I was wrong there -- the publisher
  actually does
  read the scene structure to find material references etc., I
  guess to
  know what textures etc. it needs to put in the zip, so it is
  indeed
  possible there is some bug there if it doesn't take into
  regard entities
  without mats like cameras. So this may be worth a try too.
 
  ~Toni
 
 
   The people who had problems: did you wait for long?
  
   The fact that the GUI status bar now gets stuck does not
  mean that he
   tool got stuck. It just is not yet implemented so that it
  would update
   incrementally -- it jumps in big steps when everything is
  done, so the
   GUI is misleading.
  
   I read the publish code now, and the zip making part
  apparently copies
   all the textures to a temporary directory etc. which can
  take a while.
  
   This is probably made worse by that zip making being run in
  a thread in
   the same process. So if you have Naali running at
  not-ultra-high fps, it
   can be slow (Naali eats all cpu of that processor, and if
  you are on
   multicore, the other processors are not utilized for the zip
  making now
   because cpython has a global lock).
  
   So if the people who had probs can please test again, let it
  run for a
   long time, and see if a .zip file finally appears etc. that
  would be
   helpful.
  
   On the dev side I think we should port that to use a
  subprocess -- then
   it will not be slowed down by Naali mainloop with the
  rendering etc.,
   especially on multicore machines should be normal speed for
  zip making
   then. Matti R. can see an example in pychessview if wants to
  give this a
   shot. Fortunately it should be trivial, perhaps only
  

[realXtend] Re: Suggestion: WikiTree support

2010-10-11 Thread Keystone Bouchard
I wouldn't know where to start with the implementation (I'm just an
architect! ;-) - but the code is all available under BSD license here:
http://sourceforge.net/projects/wikitree3d/

In fact, someone already suggested (maybe one of you?) Naali/Taiga
extensions for the WikiTree in the discussion forum.

I think it would be absolutely brilliant to see the WikiTree built
into Naali/Taiga, and would be happy to do anything I can to help make
that happen.



On Oct 11, 12:41 pm, Peter Quirk peter_qu...@hotmail.com wrote:
 It was implemented in LSL so it should be too hard to support.
 I'll ask Jon if he's interested in helping out.

 On Oct 11, 7:47 am, Antti Ilomäki antti.ilom...@gmail.com wrote:



  Arise, ancient thread!

  Wiki-Tree looks quite interesting. I think Jon Brouchoud has read this
  list at some point, perhaps he could enlighten us a little? I wonder
  how much of the WikiTree stuff would work directly on top of Taiga /
  Naali, any guesses to how much work the porting would be?

  2010/6/2 Peter Quirk peter_qu...@hotmail.com:

   I'd like to see something like the WikiTree [http://sourceforge.net/
   projects/wikitree3d/] (with Naali/Taiga extensions) included in the
   base distribution. Making it easier for people to build, create
   checkpoints, revert to a previous design, etc. would be really
   helpful.

   --
  http://groups.google.com/group/realxtend
  http://www.realxtend.org-Hide quoted text -

  - Show quoted text -

-- 
http://groups.google.com/group/realxtend
http://www.realxtend.org