[SoC 2006] Softimage XSI Plugin

Threads related to Google Summer of Code
Lodes
Google Summer of Code Student
Google Summer of Code Student
Posts: 228
Joined: Mon Mar 17, 2003 12:02 am
Location: San Jose, CA, USA

[SoC 2006] Softimage XSI Plugin

Post by Lodes »

EDIT: My proposal has been submitted. Thank you all for your feedback.

I am not done with the proposal yet and I want to add a schedule to it and possibly review it a little. What do you guys think about the proposal? the project?

Constructive criticism is very welcome.

Thank you.

Old Proposal:
OGRE 3D Summer Of Code Proposal
Lois Desplat


The Proposal:

A plugin to Softimage XSI that would be similar in function to that of Ofusion for 3dsmax. The plugin/tool will allow artists to preview their models in an Ogre viewport in real-time and/or when they push a button/keystroke. The plugin will have a complete Ogre material editor so that artists can use 100% of the features of Ogre's material system. A support for different scene managers will also be included (all the scene managers that Ogre comes with by default and the oFusion one). This obviously, includes previewing of static meshes as well as animated meshes (shape or skeletal animations).

Why?

It is often said that Ogre needs better tools and this is the ultimate tool that Ogre can have. Since Ogre is a graphics engine and nothing else, tools that are specific to an application cannot be back ported for general Ogre use. This tool will allow an artist to create models that will look exactly the same in their application. It significantly decreases the amount of hoops that an artist has to go through to be able to get art in an Ogre application. In this situation, all their work is done in Softimage XSI and by pushing an export button, it will look exactly the same in their application because they have been able to preview that model all throughout the creation of their art.

If you need more convincing then go look at the oFusion official page and oFusion forums and you will understand.

Why Me?

I am going to be a Senior at San Jose State University in California. I am currently going for a BS degree in Software Engineering. I own Softimage XSI 5.1 Foundation and Visual Studio 8.0 Professional. I have been signed up in the Ogre forums since March of 2003 and have been following its progress since then. I have played with Ogre extensively but I have never finished anything because I had no serious plans to do so. I plan to write a flight simulator using Ogre as my graphics engine and have been doing lots of research as to how to go about it and I am pretty much ready to start. One thing that I think could really boost my productivity is that since a Flight Simulator requires lots of art is that I have a clean and fast pipeline from the program with which I create art to an Ogre application. So, this proposal is a project which I will be in for the long term. I plan to improve and support this plugin way past the 2006 SoC.

Methodology To Tackling This Project:

The research part of this project is basically done. I know that it is feasible to do this with Softimage XSI 5.1 Foundation because of the Custom Display Host feature. I know that I can create custom UI elements as well. I also know the Ogre material system and the Ogre manual has a thorough documentation of it. I also have access to the full code of the XSI export code written by Sinbad (Steve Streeting) which will be a very good reference.

It is my intention to always have a working build. I am going to be adding one feature at a time and then testing that feature and testing that it does not interfere with others. This is because I am guessing that I will have a lot of problems with the synchronization between Ogre and XSI.

Almost all the UI code will probably be implemented in script (JScript, Python, ...), while the C++ code will only declare and implement commands that allow Ogre and Softimage to communicate and synchronize (models, time, ...) between each other.

Features:

- Real Time and Push-button previewing of models in Ogre Viewport.
- Full Ogre Material Editor.
- Real-time shader support (Artists can create real-time shaders, Cg, HLSL, GLSL, in XSI and thus the material editor needs to be able to use them)
- Ability to export (that's already done by the current exporter and will probably use the same or similar code, this tool might actually reside side by side with the current exporter)
- Ability to play animations in XSI and see them play at the same time on the Ogre Viewport.
- Support for official scene managers and the oFusion scene manager. (If designed correctly, other people could then have it support other scene managers without any problems)
- Run in Windows and uses options that will make it easy to get a Linux Port out but Linux support is not planned for this proposal.

Challenges:

The major challenge in creating this tool/plugin is that XSI is a very complex program and I will probably have to fight it to get what I need. Thankfully, I have a pretty good knowledge about Ogre and thus this side of the program will be much easier to deal with. I predict that I will most probably get bogged down getting the real-time viewport to properly synchronize with the model. The real-time preview of materials will be relatively easy to do (since the material editor will all be created by me), but I will probably (at first) not include the real-time support when an artist is editing the mesh.

Conclusion:

I am confident that I can tackle this tool. There are about seven features listed here and the real meat of the program is in the Full Ogre Material Editor and that will be what I will be focusing on as soon as I get an ogre viewport with an XSI model rendered in XSI. The success to creating this tool is all about separating all the components and making sure that each of them work individually so that they can be combined together. This is why maintaining a working build of the project along with adding features one at a time and testing them will deliver a working product on time.
Submitted Proposal (as original with typos and all):
The Proposal:

To develop a tool that integrates into an artist�s modeling program to provide a one-step solution for getting art into an application using OGRE. This tool will be integrated within Softimage XSI. XSI was chosen because it is a feature rich, affordable and proven modeling program, which has been used by big name developers like Valve Software.

This tool will be made in two parts. One part of the tool will be made as a library so that other tools that use Ogre could use this library to do common things such as:

"code to get mesh info (vertices num, indices num, vertex buffer list bones list/hierarchy) as list of string properties , some code to get texture list in a material, material info as list of properties, xml serializers, buffer optimisation, animation list (to check difference between modeler and results), animations blender, Ogre Resource group handling... " Tuan Kuranes, on the forums.

Why?

It is often said in the OGRE community that OGRE needs better tools and this is the ultimate tool that there can be for artists trying to get art into OGRE. Since OGRE is a graphics engine and nothing else, tools that are specific to an application cannot be back ported for general OGRE use. This tool will allow an artist to create and preview models in XSI that will look exactly the same in their own application. It significantly decreases the amount of hoops that an artist has to go through to be able to get art in an OGRE application. Currently, artists that create models in XSI have to export the model, then open up their application and check that the model has been correctly exported. Odds are that at that time, the artists will also need to edit the material files that the exporter created because they are not 100% correct. This tool will make this a one-step solution.

The library is being created because of a strong community need. Every since, I have posted an old version of my proposal on the forums, this has been asked by various prominent members of the community. This library will provide such commonly used functions in tools that it should be a huge success.

Why Me?

I am going to be a senior at San Jose State University in California. I am currently going for a BS degree in Software Engineering. I have been part of the OGRE community since March of 2003 and have been following its progress since then. I have played extensively with OGRE and am quite familiar with how to use it and some of its internals. In Fall 2005, I took a Software Engineering class that made us go through the entire process of creating a software application. We went all the way from the planning to the implementation. This gave me a great amount of experience, with different software process models. I have also made various small software applications, the last one, created for some research at Cisco, that I made needed to record keyboard, mouse and network activity to find patterns in infected zombie computers.

I plan to support and add features to this tool much beyond SoC 2006 because I will start working on a game that is Ogre powered during Fall 2006 and beyond. This game has a high content requirement, and thus I plan to use this tool extensively.


Methodology To Tackling This Project:

I already know that this project is feasible. I know that what I plan to do is possible with OGRE, and also possible with XSI thanks to its extensive SDK that allows developers to create new GUI screens and bind windows to its viewports with its Custom Display Host technology.

I will be able to use a lot of already created code from the XSI exporter (which is open source and created by Steve Streeting, the creator and maintainer of OGRE). The existing code will be adapted to providing quick and real-time preview of XSI models into an OGRE powered viewport.

It is my intention to always have a working build at the end of each day. I am going to be adding one feature at a time and then testing that feature and testing that it does not interfere with others. It is important to do it component by component because it will allow me to make sure that each feature is implemented completely.

The library will probably be built as a static library with a liberal license. Functions identified as being common in usage by the community, will be backported to the library and redesigned (if necessary) to match its general nature.

Features By Order Of Implementation:

1) Real Time and Push-button previewing of models in integrated OGRE Viewport (The current exporter already creates the Mesh/Skeleton/Material in-memory already and thus it will be used since it already works).
2) Ability to export
3) Ability to move lights and cameras in XSI and have them move at the same time on the OGRE viewport
4) Ability to play animations in XSI and see them play at the same time on the OGRE Viewport.
5) Full Ogre Material Editor.
6) Real-time shader support (Artists can create real-time shaders, Cg, HLSL, GLSL, in XSI and thus the material editor needs to be able to use them)
7) Release of the library of common Ogre functions (the library will be implemented all throughout the project, and new features added to it probably long afterwards).
8) Support for official scene managers and the oFusion scene manager. (If designed correctly, other people could then have it support other scene managers without any problems)
9) Run in Windows and uses options that will make it easy to get a Linux Port out but Linux support is not planned for this proposal.


Some Deadlines:

June 24: Have features 1-4 completed and possibly have 5 under early progress.
July 20: Have feature 5 completed, with feature 6 under progress and feature 7 near completion for its first release. Get community to use the tool to get feedback.
August 18: Have all features completed.

Conclusion:

I am confident that I can tackle this tool. There are nine features listed here and the real meat of the program is in the Full Ogre Material Editor and the library of common functions. The success to creating this tool is all about separating all the components and making sure that each of them work individually so that they can be combined together. This is why maintaining a working build of the project along with adding features one at a time and testing them will deliver a working complete product on time.
Last edited by Lodes on Sun Jun 10, 2007 7:36 pm, edited 3 times in total.
User avatar
xavier
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 9481
Joined: Fri Feb 18, 2005 2:03 am
Location: Dublin, CA, US
x 22

Post by xavier »

IMO, I would scale it back to real-time render/animation preview plus material editor and add shader editor support if time allows. I know how much time Lioric spent on oFusion, and that was done on a paid contract, and that's all he did, IIRC.

However, I do fully agree that the more and better DCC tools there are for Ogre, the better off the project is in the long run. :)

[Thinking out loud here]
I wonder what benefit there might be to decoupling the design from the actual modeling tool, and developing against a "modeling platform layer", to make it more portable to other tools such as Maya, which also has a decent API...
[/Thinking out loud]
Lodes
Google Summer of Code Student
Google Summer of Code Student
Posts: 228
Joined: Mon Mar 17, 2003 12:02 am
Location: San Jose, CA, USA

Post by Lodes »

A big problem I have is figuring out how long each feature will take, so it might indeed be better to cut the shader feature from the proposal so that I can be sure that I deliver what is in the proposal. In the end (after SoC), this feature will be in because I really do intend to support this.

What you are thinking is interesting and I believe someone was working on that a long time ago. He had developed some very cool stuff. I really cannot remember what his name was or what he called his project but it must be in the forums somewhere. Frankly, it sounded very complicated and not something, I believe, I could develop that produces something useful at the end of three months. I'll try searching the forums for it.. but I don't even know where to start with the search. The showcase and artists forum did not exist back then.. so it's probably in developers or general?

Even if you developed something like that though, you would still need to interface with the modeling programs and provide a communication layer. Here I have to build a communication layer (which might be more complicated to write than if you had a framework) which is the meat of the program along with some GUI.
Lodes
Google Summer of Code Student
Google Summer of Code Student
Posts: 228
Joined: Mon Mar 17, 2003 12:02 am
Location: San Jose, CA, USA

Post by Lodes »

Wooo found it. I need to read it again and see if it could modify my proposal.

http://www.ogre3d.org/phpBB2/viewtopic.php?t=4516
User avatar
xavier
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 9481
Joined: Fri Feb 18, 2005 2:03 am
Location: Dublin, CA, US
x 22

Post by xavier »

I would expect the "application layer" to be developed by someone else, probably in tandem, but you are probably right -- too much to take on in an already tight schedule. Possibly something best left for refactoring afterwards; this would let someone else or some other team work on the tool app layer without compromising your project's timeline.
User avatar
Kencho
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 4011
Joined: Fri Sep 19, 2003 6:28 pm
Location: Burgos, Spain
x 2
Contact:

Post by Kencho »

My suggestion, design the whole tool, or at least the key points, and leave the shader editor part if there's no room for it. Duh... let me explain. My idea is to do a good design that will let to plug the shader editor easily later. You probably won't find the time needed to complete that part, but doing it will be far easier later, in case you or someone else is looking for doing it :)

About time estimation. You seem to know pretty well the business for this tool (the XSI interface, Ogre interface...), so probably can easily determine use cases and number/complexity of classes needed. I propose you this time estimation method based on use case points. I used it for my graduation project, and it returned me 10 hours more than I really needed (600+ hours -A good approximation ratio ;))

Xavier, about your loud thoughts, isn't that the philosophy behind Collada? :?
Image
reimpell
OGRE Contributor
OGRE Contributor
Posts: 570
Joined: Mon Mar 01, 2004 10:35 am
Location: Hamburg, Germany

Post by reimpell »

Using few technobabble, having features that can easily be turned into deliverables and exlicitly stating expected challenges are good qualities of the proposal.

In the real proposal I would make no mention of the Ofusion plugin, even if you plan to include support for their scene manager. Otherwise it becomes hard to argue what your unique selling point is.

Be sure that one can read your abstract without any prior knowledge about Ogre or Softimage XSI. Conserve technical terms for detail sections.

As Google is probably not interested in spending money to Softimage in a direct or indirect way, you have to find very good reasons why you choose Softimage XSI and not, e.g., Google SketchUp.
Lodes wrote:I have never finished anything because I had no serious plans to do so
Please remove sentences like this without substitution. They hardly give any good reason why you are the best individual for this job. Do you have any successfully finished projects that you can mention (not necessarily computer programs)?
Lodes wrote:I own Softimage XSI 5.1 Foundation and Visual Studio 8.0 Professional.
I would also remove such sentences. Everyone expects you to have or buy the necessary tools for your application.
Lodes wrote:The research part of this project is basically done.
For proposals, either something is done or it is not done. Make sure and convince that your preliminary work is done.
Lodes wrote:I know that it is feasible to do this with Softimage XSI 5.1 Foundation because of the Custom Display Host feature.
Proving the feasibility is a very good idea, but ensure that it doesn't sound as if it is due to a single technical feature.

Good luck with your proposal!
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Post by sinbad »

As you already know, I fully support this idea. I think you've got a good start on the proposal there.

I think you could re-use / refactor a majority portion of the existing exporter to handle the guts of the mesh / skeleton / material exporter (using the in-memory Mesh / Skeleton / Material directly in the display host rather than using a serializer) leaving you the lions share of the time for the important part - tool integration. Because the existing 3dsmax exporter didn't construct in-memory OGRE objects (it exported to XML), Lioric had to reinvent the mesh / skeleton export from scratch, so you have an advantage there with the existing XSI exporter.

I don't think it's too ambitious, I think you just need to break it down and work on one complete feature at a time, and you seem to already have that in mind which is good. You don't have to finish every feature, but each feature you do should be complete, that way whatever happens you have something useful to show for it at the end. I like agile development philosophies like DSDM myself - rank your desired features in order of importance and set yourself time boxes in which you'll get as much done as you can, in that order, then forcibly review your priorities afterwards. Helps to avoid getting bogged down fighting a particular feature and losing sight of the big picture.

I agree you should start with getting the custom display host working, with the transfer of data organised using the existing exporter code. You know that works already so you only have to worry about the CDH part. From there you can build up layers of functionality. I think your 'ability to export' option should be higher, directly after the CDH - because if you use the existing code to populate the in-memory objects, it's only a case of calling a serializer and you're done, and that code is already working. No point reinventing the wheel here, the big value you're adding (I think) is tighter integration so the artist doesn't have to switch tools (XSI, OGRE test app, material editor etc). Also, it's an important skill to be able to take existing code and refactor / adapt it to a new situation, in many ways more important in the real world than being able to write good code from scratch, because we rarely work in a bubble. Using the existing XSI exporter code is not cheating, it's being sensible, allowing your project to get much more useful things done rather than recreating what's already done.

I agree that the 'application layer' is a good idea but I don't think it can be done on this timescale, and I don't think you can realistically do it unless you have several modelling tools to experiment with (and the time to do it!)
User avatar
xavier
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 9481
Joined: Fri Feb 18, 2005 2:03 am
Location: Dublin, CA, US
x 22

Post by xavier »

Kencho wrote: Xavier, about your loud thoughts, isn't that the philosophy behind Collada? :?
Ya know, for some reason that's the first thing that came to mind when I woke this morning. ;)
User avatar
xavier
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 9481
Joined: Fri Feb 18, 2005 2:03 am
Location: Dublin, CA, US
x 22

Post by xavier »

sinbad wrote: I agree that the 'application layer' is a good idea but I don't think it can be done on this timescale, and I don't think you can realistically do it unless you have several modelling tools to experiment with (and the time to do it!)
That's one of the reasons I mentioned that it should be done by someone else on a different timeframe -- I have access to various versions of Max and Maya, and I could probably come up with a Foundation 5.0 license if I had to as well. The wildcard of course is Blender -- unless we wanted to engineer a layer separate from the Python API (that sounds like a freakin' nightmare though).
Lodes
Google Summer of Code Student
Google Summer of Code Student
Posts: 228
Joined: Mon Mar 17, 2003 12:02 am
Location: San Jose, CA, USA

Post by Lodes »

Thank you for all the great feedback. All of you have given me very good advice and insight and I am taking it all to write my final proposal which I will probably turn in tomorrow.

Thanks again.
User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2653
Joined: Wed Sep 24, 2003 8:07 am
Location: Haute Garonne, France
x 4
Contact:

Post by tuan kuranes »

Perhaps Application Layer is perhaps feasible if multiples Soc project goes for it. One for XSI, one for Blender, and both working on an Ogre Pipeline Tool API. Therefore giving access to this work for every ogre users to build their own in-house tool integrated into their developpement pipeline.
Lodes
Google Summer of Code Student
Google Summer of Code Student
Posts: 228
Joined: Mon Mar 17, 2003 12:02 am
Location: San Jose, CA, USA

Post by Lodes »

Hi Tuan Kuranes,

You submitted a similar comment to my SoC application and i'd like to comment here first.

I see how it would be very interesting and nice to have but I still do not understand what would go into this layer.

I know of one thing that could be there and that is the Material Editor. In XSI, all you have to do is create your own window and tell it that it is parented to XSI and that window can now be part of any XSI viewports. That means that one could, if other modelers act the same, create a material editor that could be used by any modelling program.

I have reservations about this though. One is that it wouldn't have the look and feel of the modeler that the artist is using (I think that is a pretty big point). Second, I am not really sure how that program will communicate with each modeling application. I know how XSI handles all this, but I don't know how other modeling applications do.

I have problems, apart from the material editor (which is a big chunk of my proposal), seeing what code would be in common. I have ideas of how I could do some other things that would be very useful to users, but I just can't see the merit of an "application layer".

For example, I can see how letting the users decide how and where a model is exported could be useful (maybe they have an external fileserver where they want to save the file, maybe they want to save the file on their local disk, maybe they want to send it via the net). Of course, this idea is getting less and less "good" because source control is getting integrated into modeling apps.

I can see how letting the users plug their own game in the viewport is very interesting and this is something that I will be really looking for throughout the development of this tool and something that I will formalize after the SoC.

Oh also, some people have said in this thread that this "application layer" sounds like collada. You can see how unclear this "application layer" is. Can you describe it in more details?
User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2653
Joined: Wed Sep 24, 2003 8:07 am
Location: Haute Garonne, France
x 4
Contact:

Post by tuan kuranes »

I stumbled on that when making the new cegui mesh viewer, as every tool would need the exact same features...

Some code to get mesh info (vertices num, indices num, vertex buffer list bones list/hierarchy) as list of string properties , some code to get texture list in a material, material info as list of properties, xml serializers, buffer optimisation, animation list (to check difference between modeler and results), animations blender, Ogre Resource group handling...
All Ogre resource manipulation code would goes in that library.


XSI app would just give access to them through a XSI gui.

My Idea is mainly to share code between all plugin/tools related to Ogre,
Not Gui code, just Ogre manipulation Code which would anyway surely gain to be separated from gui, and be shared as much as possible.

It's more about a Ogre API library
Lodes
Google Summer of Code Student
Google Summer of Code Student
Posts: 228
Joined: Mon Mar 17, 2003 12:02 am
Location: San Jose, CA, USA

Post by Lodes »

Oh I see what you mean now. I believe it is a very good idea and definitely something that won't add a significant amount of time to me getting my proposal done during the SoC timeframe.

I believe a new thread should be created somewhere in the Ogre forums, to list all the specific features of what such an API would have to do. I would have no problems contributing to such a project as I write the XSI plugin.

Maybe just centralizing such a thing on the wiki and adding all the "code samples" to do that could be posted on the wiki and regularly compiled into a zip/rar file with all the code samples might be good enough?
Lodes
Google Summer of Code Student
Google Summer of Code Student
Posts: 228
Joined: Mon Mar 17, 2003 12:02 am
Location: San Jose, CA, USA

Post by Lodes »

Re-read your comments and I think I should do what you suggested in the comments for my application.

I am going to change my application to now be about two things. The tool will remain unchanged but in addition, I will design and implement (in conjunction with other SoCers if they have something similar and people in the community, like you Tuan) parts of this library that does the grunt work to get an easier output to deal with.

I'll update my application in a few hours.

EDIT: updated my application. Thanks for great idea and feedback.
Chr
Gnoblar
Posts: 23
Joined: Mon Aug 08, 2005 10:39 am

Post by Chr »

is this proposal only for xsi 5.1?
User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Post by jacmoe »

It would be good if it would be available for XSI 5.0. (Probably just a matter of recompiling it). :)
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Post by sinbad »

5.0 and 5.1 plugins are binary compatible anyway so I believe the question isn't relevant.

4.2 has an older interface so I wouldn't expect this to be supported. I don't support 4.2 with the official Dagon XSI exporter since the interface to shapes (for pose animation) was tidied up in XSI 5.x and thus the exporter won't compile on 4.2 anymore. You have to use the previous Azathoth exporter for 4.2.
Lodes
Google Summer of Code Student
Google Summer of Code Student
Posts: 228
Joined: Mon Mar 17, 2003 12:02 am
Location: San Jose, CA, USA

Post by Lodes »

There is one major change from XSI 5.0 to 5.1 which might make it a bit hard to do.
SDK enhancements to enable mixed-pipeline deployment

With new self-installed custom operators it is now easier for developers to create C++ and scripted operators in SOFTIMAGE|XSI v.5.1. In all, over 200 new SDK features, commands, classes or functions have been added to improve customizability, including new custom menu anchor points in the main command panel and view manager.
I went through the pdf which had more detailed information and from what I could see, it should not be too much of a problem for me to develop for 5.0.1. I'll install 5.0.1 alongside 5.1 and will try to make it work on both versions. (EDIT: I guess I'll just develop for 5.0.1 and have both versions work, hopefully I won't need 5.1 functionality :) )

I guess you guys don't want to upgrade to 5.1 because you already have everything in place? I don't know of any other reason to stick to 5.0 otherwize.

Note, that I cannot develop for 4.0, because the custom display host is not in the foundation version. So a 4.0 version is definitely not possible.
mcasaday
Gnoblar
Posts: 2
Joined: Sun Oct 06, 2002 11:19 pm

Post by mcasaday »

Lodes wrote:I guess you guys don't want to upgrade to 5.1 because you already have everything in place? I don't know of any other reason to stick to 5.0 otherwize.
Indeed. 5.1 is a free download if you already have 5.0. (At least, it was for me.) I can't for the life of me imagine why supporting only 5.1 would be a problem.
Lodes
Google Summer of Code Student
Google Summer of Code Student
Posts: 228
Joined: Mon Mar 17, 2003 12:02 am
Location: San Jose, CA, USA

Post by Lodes »

Might be time for a progress update. Ogre can have multiple embedded windows inside XSI, and you can obviously easily load meshes and such. You can choose to export your xsi models directly into the viewport (works for meshes, still have to get around to skeletons and materials). Ogre camera is updated along with the main XSI Camera. Created GUI property screens and put them into views so that you can easily reorganize them however you want in your own custom views.

I am probably missing some things, but I have a whole lot of issues that need to be taken care of. This is why you should not even try to get the code from cvs (ogreaddons/xsitool) because it won't be of much use yet :)

I do have some questions though:

- How to handle cameras?
I have no idea how to handle cameras. Right now I am updating the Ogre camera from what the default Camera created by XSI does. But ideally, if you have multiple Ogre viewports, you might like to have different cameras for each OgreView (1-1 relation though). Is it okay if I create OgreCamera1-4 in your scenes? Any ideas on how to handle that? How does oFusion handle that? Should I let the artist create the cameras and then choose which one to view in the OgreView and pick the default camera as default?

- How would you want a material editor to be?
I have ideas on how to make the material editor and how to lay it out but I am interested in what people think would be a good visual design.

I plan on letting you create small Ogre windows where you can preview each technique, each pass, combination of passes, each material along with seeing the final result immediately on your mesh in your OgreView(s) you have open.

Do you want a button to see the written material script so that you can edit it manually?

I plan on laying it out the following way.

Image

This is all currently coded for XSI 5.1. If I can backport it to 5.0 in a day, then I will do so before doing an official release. It will also be tested under 5.11, but sticking to 5.1 right now.
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Post by sinbad »

I think things are coming on well, even if there are a lot of things in a state of transition / fluctuation right now. Keep it up :)

Cameras
I don't think an Ogre view should need to have an XSI camera object. You should be able to bind it to an existing XSI camera, but that shouldn't be required, in the same way that all the regular XSI views are independent of scene cameras except if you specifically tie them to one.

Materials
I'm going to defer to the artists here since I think a coders view may be rather different :) I do think thought that an option to edit the material script manually should only be added if you then synchronise those changes back into the GUi view. I'd leave that as a 'might be nice, but very optional' feature and concentrate on making the gui aspect as good as you can.
User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Post by jacmoe »

Really looking forward to this! :)
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Bloodypriest
Goblin
Posts: 223
Joined: Thu Aug 18, 2005 2:54 pm

Post by Bloodypriest »

Yup looking forward to this too.

This will lead XSI in the lead for OGRE support. As you can tell, I'm really an XSI man.
Post Reply