Jonne Nauha kirjoitti:
Anyways, it's a bit sad that Naalis building capabilities are what they are and you and most other need to use old viewer to upload meshes/textures and build with old viewer then just view with naali. I think there has been some improvements lately but its not nearly enough. I am starting from tomorrow the work with world building. I would have liked to do this in c++ side but i was denied that right. So learning up and rewriting some of the python code will take time. The aim is to have own dedicated scene of widgets for building mode. We will see how
Apparently there was a misunderstanding there. Jonne's boss told me that they would want to work on object editing, but in c++. I asked what they would do, and he replied (at least in my mem, these things are fuzzy :): the exact same thing as the current, but in c++. I figured that makes no sense at all, we have better things to do than reimplement existing things as they are. And added that what Jonne had talked earlier about designing the UI for it and possibly making a new scene etc. sounded like it might make sense. That then translated to work in c++ being somehow denied overall :p That is not the case.
Me and Jonne were talking now again on irc, and like discussed in sprint planning there are three fronts going on with editing now:
1) Under-the-hood dept: There are things missing in the networking & renderer still that results in missing functionality. Petri was adding sending packets like duplicate and undo earlier and those work, but didn't get to finish the most complex ObjectUpdate sending. Naali wasn't storing all the info it gets in ObjectUpdates, which is needed to send back also, and he added some of those (objectflags, some texture entry things, etc?) but wasn't sure what e.g. time dilation should be. We talked earlier with Jukka and Ali that they could finish those, but apparently haven't had time, so as Jonne seems to have time for editing now this is a clear place where to add stuff that immediately results in new func without porting needed. Another similar thing but on the renderer side is doing frustum queries so that multible objects could be selected with a rectangle. Petri added making the rectangle to the UI side in March and I later added the stub frustum query to renderer and made the ui call that, but the actual Ogre frustum query using impl is missing still. Implementing these kind of things in the c++ net & render code add good basic feats immediately.
2) 3d tools: Nathan Letwory started work on RealXtend core dev in general (hi! :) yesterday, we agreed on it earlier the idea being that he'd take main responsibility for the editing tools 'cause Petri is busy with other things and I also don't have much time for it. Then (some weeks ago) we didn't know that Evo was also growing interest there. Nathan is now adding support for local transformations and other basics to the 3d manipulator widgets, and figuring out the py side of the codebase in general so that can fix and improve things.
3) Ui design & future work planning: Jonne has had some ideas for editing UI, sounded pretty much like what we discussed back in December when the UI team with Tomi, Jonne, Ryan et al had the sessions where the current ether ui and the inworld buttons layout etc. was designed. A basic thing is that modes should be well visible: current Naali is like slviewer, where whether the editing dialog is open or not also sets the mode, whether mouse clicks sends touch events to server (default mode), or work for selecting objects. I showed then the Spore Creature Creator UI, where the different modes are clearly visible with big buttons that also change the layout bringing in the tools needed for that mode etc., and there seemed to be consensus that something like that would be good. In sprint planning we agreed that it's good for the UI team to continue and tackle that next -- earlier designing building tools were postponed 'cause login + basic inworld layout was done first. I think the results from this process have been good, no reason why building would deserve less effort, and I think there it is critical to have people who actually do modelling, building, texturing etc. to give their input of what the *workflow* should be. Jonne's ideas sounded also similar to what QtOgitor does - looking at that for ideas, reuse of code & gfx or even possibly integration is one thing to do.
So with 1) and 2) now we can now get immediate improvements, and with 3) get to know what would be good to implement. Then we can see with what lang it is good to do what. Nothing of the current impls is wasted, 'cause the underlying things in networking and renderer are needed anyway despite what the UI is like, and so is the 3d math in widgets even if those are ported to c++ later.
The current obedit ui has not been designed at all, has just grown from what I did in August when tested QT Designer for the first time when was testing javascript etc. and happened to make a simple editing dialog just 'cause that came to mind first :) .. and it was made functional 'cause it was simple to do, as the api that had been devved with games in mind happened to enable simple editing too.
With the lack of unit tests etc., it has been good for the py api & module system that there has been some module around so that probs have been found (e.g. with the 0.0.2 release all kinds of installation things etc). But now there are already many other modules (scene import bundled by default, others in projects) and it would be good to make actual unit tests anyway, so testing wise we survive if the previous test case is removed. So what obedit is developed in in the future can be decided just based on what is best for itself, no other concerns have to be in play anymore. I'd certainly continue it in Py, as find it's quicker to dev and results in less and better readable code, and has the side effect that ensures that the core functionality (like mouse input) provided by Naali works so that doing custom modules in py & js is possible. But there are matters of taste, so it's really up to the people doing the work. I won't be working with editing anyway, but focus now on what the py/js api is otherwise made for: allowing app specific custom functionality be loaded from servers and run in the client too (so perhaps the hardcoded c++ rexlogic module can later be replaced with a opensimlogic.js loaded from the server when you connect to a vanilla opensim server, and with another logic module being used if you connect to another kind of world ;) (that's how syntensity with its map.js works, though it does have default hardcoded behavs also).
Otherwise for building work the Blender etc. integration will continue in June - Pablo Martin of blender2crystal game will focus on that starting June 7th or so. He got funding for that from nlnet (congrats!), independently i.e. not related to the realxtend project org, but will work together with us in the planning and impl. Currently building using Blender or Max works ok for basics, but material defs fail short and logic/scripting is missing etc.
Jonne Nauha
cheers, ~Toni
On Mon, May 24, 2010 at 7:49 PM, Gustavo Alberto Navarro Bilbao <sombra.albe...@gmail.com <mailto:sombra.albe...@gmail.com>> wrote:Well, I've got the same Cable Beach Assets error, (screenshot "failed"). Following the same steps than Pedro wrote, with the exception than I used 3dMax instead Blender, these are the results: I have built in 3dMax part of a structure, and exported it using OgreMax, the meshe and the baked texture. Then I've created the alien plants and the silver tree, and exported them in the same way. Well, in world (Taiga 0.1.2), using RX 4.2, to upload the meshes and the textures and put them in the prims, I get the objects than you can see in the "baked" screenshot. If I use the Naali 0.2.2, just as you can see in the other screenshot, curiously, the estructure withe the baked texture looks right, better really, but the plants lost the meshes. It is a very strange effect, since all meshes have been created and uploaded in the same way. Alberto ----------------------------------------------------------------------- 2010/5/24 Toni Alatalo <ant...@kyperjokki.fi <mailto:ant...@kyperjokki.fi>> pedro kirjoitti: I made a statue consisting of 2 meshes in blender and uploaded it, using viewer 0.42 But when i logged in with naali the lower part of the statue didnt rez, but in 0.42 it was all ok.We had something like this on one test server, and I came to suspect that it was a server side problem -- it not storing the mesh or something. It may be that it shows in the 0.42 with which you uploaded if it went to it's local cache upon upload (am not totally sure whether that's how it works). What we saw was that one person uploaded a mesh using rexviewer, and no one with Naali could see it, so they thought it was some strange new Naali prob. Then we noticed that it didn't show for others using the old rexviewer either, only for the person who uploaded, and figured it was a server prob. Too bad the prob disappeared before at least I got to hear what it was (someone fixed some server db conf?) Next thing i linked the prims and tried to copy them by holding shift and dragging which resulted in new prims without any meshes assigned to them.Sounds consistent with the server not having the meshes. on the server console i get the following error message: 22:34:30 - [CABLE BEACH ASSETS]: Failed to fetch asset metadata from http://192. 168.1.35:8003/assets/e8af4a28-aa83-4310-a7c4-c047e15ea0df/metadataI think this is unrelated, but am not totally sure. ~Toni On May 22, 8:13 am, Denis Tarasov <dtaras...@gmail.com <mailto:dtaras...@gmail.com>> wrote:I found out what was the problem with ogre rendering. Things works well with 0.42 viewer, but not with any derivatives, renaming executable/and or changing main window title will disable this feature. Looks like new code detects what viewer is running and only sends "running rex mod" to the viewer named "realxtend". Denis Tarasov On 21 май, 12:40, Denis Tarasov <dtaras...@gmail.com <mailto:dtaras...@gmail.com>> wrote:Hi, just downloaded new binary. Seems that it works better than previous one. Still, i'm confused becouse you said> - Added missing "running rex mode" flag to login response. realXtend 0.4* viewers now don't need to manually switch to ogre rendering. but this does not work, 0.42 viewer still starts without ogre rendering, so shift+R still needed. Best regards, Denis Tarasov On 19 май, 18:33, Jonne Nauha <jonne.na...@evocativi.com <mailto:jonne.na...@evocativi.com>> wrote:Good afternoon, We have just released the new Taiga 0.1.2. This release mainly has crash fixes, more webdav implementation and the newest config creator. Below you can read the whole changelog. Get started herehttp://wiki.realxtend.org/index.php/Getting_Started_with_Taigaonthe <http://wiki.realxtend.org/index.php/Getting_Started_with_Taigaonthe> updated wiki page. Notes about a known bug in the config creator with regions.ini can be found here:http://wiki.realxtend.org/index.php/Getting_Started_with_Taiga#Known_... Please read this before you start up your servers the first time to ensure a smoother Taiga experience :) *Changelog* *Features* - Config Wizard now lets you change modrex database settings. - Sending webdav inventory url in login response to client for OpenSim agents. - Broadcasting webdav appearance url via ModRex for OpenSim agents. - llTextBox script function *Bug Fixes* - Webdav put handler now checks for overwrite header and replaces the existing asset if exists. - Webdav encode/decode fixes for request paths. - Added missing "running rex mode" flag to login response. realXtend 0.4* viewers now don't need to manually switch to ogre rendering. - General crash fixes You can post here about problems in setting up/running the servers so we can try to help! Best regards, Jonne Nauha realXtend developerhttp://www.realxtend.org/http://www.evocativi.com/ --http://groups.google.com/group/realxtendhttp://www.realxtend.org--http://groups.google.com/group/realxtendhttp://www.realxtend.org--http://groups.google.com/group/realxtendhttp://www.realxtend.org-- http://groups.google.com/group/realxtendhttp://www.realxtend.org-- http://groups.google.com/group/realxtendhttp://www.realxtend.org -- http://groups.google.com/group/realxtendhttp://www.realxtend.org
-- http://groups.google.com/group/realxtend http://www.realxtend.org
