I just started working with Papervision a couple days ago - which is difficult given that I 1) don't own Flash (I'm using FlashDevelop instead) and 2) have no idea what the hell I'm doing at all.
for the moment it doesn't load the texture in Firefox, but it does so in IE. I have no idea why Firefox is being a big fat jerk about it, but it DOES load the model at least, which gives me some hope.
It took me a while to get the export script to work, so these are the settings I used, in case you're experiencing problems with the models not showing up (took me forever to get it to work...):
Triangulate the mesh and select "Triangles" in the exporter
Select the objects you want to export and turn on the "Only Export Selection" option
Turn off "Bake Matrices"
Turn off "Sample Animation"
Turn on "Disable Physics"
Turn on "Only Current Scene"
Everything else below that is off.
When you export it, open the resulting .dae file in a text editor, go down to where it starts talking about the texture and remove the path information. That way when it's on the web, so long as the texture is in the same spot as the model it will render. Actually... that might be the reason Firefox isn't liking my texture... Maybe I should add the HTTP: path in there... hmmm...
I've started finding that conventional low-poly modelling isn't really working. Papervision seems to cull intersecting polygons, so all your models have to be water tight to stop things disappearing.
my process is now straight from cd4 to papervision thanks to the DAE model loader.
the developer even replied at that thread,- so far it seems to be able to handle more triangles as most of the other engines though it only handles static models
I like papervision a lot more than Sophie3d, Sophie is much (MUCH) easier to get models up and working in, but once you do get them up it seems like there is nothing else to do but spin it round really.. and somehow Sophie doesnt seem to handle the objects as well as Papervision does....also the controls for Sophie are not really user friendly to a non-3d creator. Papervision seems better able to become REAlly interactive and user friendly to the lowest common denom. once embedded. They are both flash based I guess tho so sophie has some hope.
According to MadVerts up there it looks like one of the better ways to import models is to use the Collada format - it does seem convoluted though.
Ive found this site which creates a max and maya collada plug-in, but i think you have to pay for it >< HERE im not sure tho because you have to at least register to find out how to download, which in iteself is a clue i think.... and I havent done that tho either. Their site looks suspect to me. Im looking at using blender to create my collada files perhaps, to then take into Papervison HERE.
Im really interested in this for sure so I hope this thread comes alive! Ive never learned any code before but I think papervision might be worth finally learning a language...
Hawken does the DAE format also include animation? I think Collada can take this information as well and so might therefore be a step above. (and then 2 steps back for being so damn hard to use)
Im really interested in this for sure so I hope this thread comes alive! Ive never learned any code before but I think papervision might be worth finally learning a language...
papervision is no language,- its a Actionscript 3 package to be used with flex, Flash CS3/CS4 or any AS3 supporting environment that can and publish flash movies
collada (*.DAE) is bloated text format similar to ASE or OBJ but bigger because of the XML syntax- might not be a wise choice for each project.
Papervision also supports *.3ds which is a binary format and already alot smaler.
As for animations: the most examples I have seen with Sandy or Papervision were Quake2 model formats that store vertex animations (keyframe vertex snapshots with linear interpolation).
Papervision 3D is a project that is in constant flux. The current development version is usually quite a ways beyond the current stable version. As such you will almost always be trading off stability for performance and features.
DAE is very cross-platform and cross-engine compatible because of the simplicity of the format. It is essentially XML, and that makes it very easy for programs to read and parse. But because it is XML, it is going to make for much larger file sizes. Also, you are going to be limited on how much can be done with it, depending on what Papervision currently supports. I've found that most Flash 3D implementations are pushing to offer more support for Collada files.
.3DS is binary, and will take up much less space. The format doesn't have as many features, but it's size advantage makes it ideal for static meshes.
One of the keys with Papervision is to create a "template" file, and extend this template file when making your own new scenes. This allows you to take care of most of the back-end code right away, and just add to it for making individual applications.
okay... so we're now finding that .3DS run better than .DAE
It appears that .DAE doesn't support collision too well. Also, I'm not getting so many intersecting culls with 3DS on the same models.
Experimenting with animated vertices tomorrow, had to finish up the model I'm using first. Should have done a test...!
Also, just a matter of note. It is possible to convert your models into Actionscript files, and compile them directly into your flash application. This is another way to get your models in a more compressed format. But it does limit how many models you can load in, as an abundance of models will bloat your flash file and make the initial load time much longer. If you are going for a very content-intensive program, you are probably going to want to keep your model files separate and load them in only when you need them.
Blender has built-in exporters for Collada (DAE) and .3DS files. You hardly need a tutorial for exporting those for Papervision. Just go to the scripts window in Blender and use the existing exporters for those formats. Pretty self-explanatory.
We found that exporting straight from c4d as either .dae or .3ds totally screws up the materials. It appears that c4d's file formatting and papervision's parsing of these file formats are mutually in-exclusive. Although you can get a model in, it's basically screwed.
The ultimate fix was for us to export .dae from c4d, import them into 3ds max version 9 (with colladamax) and just re-export them. After doing this, the files were 99% perfect, except for a strange scaling issue that affected certain models in the scene. (which was easily fixed in the code)
The benifit of using .dae instead of .3ds is that with collada + papervision, you have greater conrol of any hierarchies that you might have set up. So for example if you have a tank with a turret, and the turret is a child object in your scene, you only need to move the tank and the turret will move with it.
Unfortunately with the .3ds file format this wasn't as easy.
To my knowledge the colladamax exporter is basically the most compatible out there, and supports animation perfectly.
I'll post the link to our project later.
The next project we'll be working on is getting models to import on demand, instead of being clumped together in one scene.
I faffed around with blender for a bit, but it screws up files imported to it (it reads c4d .dae files at about 4000% the size, whereas max doesn't) but the bewildering interface of blender made me give up before I had a real chance to check most things.
So, in conclusion, I still get to model and rig in my favourite modelling program (cinema). Then it's simply a case of running them through max9 to get them into papervision. Not an easy task when you're running an osx environment... but then again I know max very well and have finally found a new use for it.
That's good to know. The important thing is to find a workable solution that fits your needs. And I know how hard this can be in conjunction with existing Flash 3D engines. Each one handles external files differently. One of the nice things about DAE files is that you can always open them and tweak them manually. Of course, this can also be a huge pain in the ass if you are forced to do it as part of your content pipeline.
Renderhjs is lucky. He's working on his own Flash 3D engine, and is even savvy enough to write his own 3D file parsers. So he can tailor his parser to whatever modeling program he uses. The rest of us are stuck struggling with the eccentricities of our software.
One of the nice things about DAE files is that you can always open them and tweak them manually. Of course, this can also be a huge pain in the ass if you are forced to do it as part of your content pipeline.
so is ASE or OBJ all three are text based fileformats and because of that so popular still today (max ASE used in Unreal Engines, OBJ in any 3d package today as poly export/import standard). This is because any coder or technical advanced person can look into it and very quickly learn the structure.
Like I mentioned before using those formats can:
- increase the data that has to be loaded sometimes up to 10x of what it would be using arrays or binary data
- lag because of the parsing time: what the engine needs to do is converting complex text string into logical arrays holding the vertex points, UV data, face array, vertexAnimation frames,..
I have a few custom fileformats developed for 3d engines- but often they were very specific designed - and making them work with Papervision or any other popular engine is another thing. I never played with them so I dont know enough + I dont have the time but any advanced as3 writer could implement it with a example code (PM me if you want it).
Right now I dont have the time to make postings about but that will happen eventually once I have a little more time on my hands.
In case you are interested in flash and 3d (not papervision, just pure flash) some of my flashkit postings:
I've started finding that conventional low-poly modelling isn't really working. Papervision seems to cull intersecting polygons, so all your models have to be water tight to stop things disappearing.
my process is now straight from cd4 to papervision thanks to the DAE model loader.
Hey guys Ive been doing some experiments in papervision lately and got 2 models in there one on top of the other but where the objects intersect there is some wierd flickering polygons and zfighting is there a method to combat this?
most flash 3d engines have rather simplified z-depth soring mechanics. Away 3d (at first based on papervision but went its own way somehow) http://away3d.com/
has as far as I know a more complex BSP tree depth sorting/clipping appoach which will cost a little bit more CPU waste but it does a better job of intersecting objects.
the more triangles you have in those areas the more depth are sorted and the more change it stands for 1 face finding its own depth instead of flickering and fighting with others
Replies
I have so far managed to get a simple model loaded and rotating in my browser. Here's a link:
http://squigglyperson.awardspace.com/cone.swf
for the moment it doesn't load the texture in Firefox, but it does so in IE. I have no idea why Firefox is being a big fat jerk about it, but it DOES load the model at least, which gives me some hope.
It took me a while to get the export script to work, so these are the settings I used, in case you're experiencing problems with the models not showing up (took me forever to get it to work...):
Triangulate the mesh and select "Triangles" in the exporter
Select the objects you want to export and turn on the "Only Export Selection" option
Turn off "Bake Matrices"
Turn off "Sample Animation"
Turn on "Disable Physics"
Turn on "Only Current Scene"
Everything else below that is off.
When you export it, open the resulting .dae file in a text editor, go down to where it starts talking about the texture and remove the path information. That way when it's on the web, so long as the texture is in the same spot as the model it will render. Actually... that might be the reason Firefox isn't liking my texture... Maybe I should add the HTTP: path in there... hmmm...
my process is now straight from cd4 to papervision thanks to the DAE model loader.
http://boards.polycount.net/showthread.php?t=57133
the developer even replied at that thread,- so far it seems to be able to handle more triangles as most of the other engines though it only handles static models
This site here is a great starter kit to the Papervison code;
MadVertices
I also have been frequenting this site about papervision as well, seems good;
http://pv3world.com/blog/
I like papervision a lot more than Sophie3d, Sophie is much (MUCH) easier to get models up and working in, but once you do get them up it seems like there is nothing else to do but spin it round really.. and somehow Sophie doesnt seem to handle the objects as well as Papervision does....also the controls for Sophie are not really user friendly to a non-3d creator. Papervision seems better able to become REAlly interactive and user friendly to the lowest common denom. once embedded. They are both flash based I guess tho so sophie has some hope.
According to MadVerts up there it looks like one of the better ways to import models is to use the Collada format - it does seem convoluted though.
Ive found this site which creates a max and maya collada plug-in, but i think you have to pay for it >< HERE im not sure tho because you have to at least register to find out how to download, which in iteself is a clue i think.... and I havent done that tho either. Their site looks suspect to me. Im looking at using blender to create my collada files perhaps, to then take into Papervison HERE.
Im really interested in this for sure so I hope this thread comes alive! Ive never learned any code before but I think papervision might be worth finally learning a language...
Hawken does the DAE format also include animation? I think Collada can take this information as well and so might therefore be a step above. (and then 2 steps back for being so damn hard to use)
collada (*.DAE) is bloated text format similar to ASE or OBJ but bigger because of the XML syntax- might not be a wise choice for each project.
Papervision also supports *.3ds which is a binary format and already alot smaler.
As for animations: the most examples I have seen with Sandy or Papervision were Quake2 model formats that store vertex animations (keyframe vertex snapshots with linear interpolation).
It appears that .DAE doesn't support collision too well. Also, I'm not getting so many intersecting culls with 3DS on the same models.
Experimenting with animated vertices tomorrow, had to finish up the model I'm using first. Should have done a test...!
DAE is very cross-platform and cross-engine compatible because of the simplicity of the format. It is essentially XML, and that makes it very easy for programs to read and parse. But because it is XML, it is going to make for much larger file sizes. Also, you are going to be limited on how much can be done with it, depending on what Papervision currently supports. I've found that most Flash 3D implementations are pushing to offer more support for Collada files.
.3DS is binary, and will take up much less space. The format doesn't have as many features, but it's size advantage makes it ideal for static meshes.
One of the keys with Papervision is to create a "template" file, and extend this template file when making your own new scenes. This allows you to take care of most of the back-end code right away, and just add to it for making individual applications.
Here's a link to the PaperVision Template I usually use...http://www.willhawthorne.com/ModelViewer/Paper3DTemplate.as
By extending this template and overriding some of the base functions you can make Papervision Applications quickly.
Also, just a matter of note. It is possible to convert your models into Actionscript files, and compile them directly into your flash application. This is another way to get your models in a more compressed format. But it does limit how many models you can load in, as an abundance of models will bloat your flash file and make the initial load time much longer. If you are going for a very content-intensive program, you are probably going to want to keep your model files separate and load them in only when you need them.
Were you using a Blender -> Papervision tutorial previously? And chance of a link?
We found that exporting straight from c4d as either .dae or .3ds totally screws up the materials. It appears that c4d's file formatting and papervision's parsing of these file formats are mutually in-exclusive. Although you can get a model in, it's basically screwed.
The ultimate fix was for us to export .dae from c4d, import them into 3ds max version 9 (with colladamax) and just re-export them. After doing this, the files were 99% perfect, except for a strange scaling issue that affected certain models in the scene. (which was easily fixed in the code)
The benifit of using .dae instead of .3ds is that with collada + papervision, you have greater conrol of any hierarchies that you might have set up. So for example if you have a tank with a turret, and the turret is a child object in your scene, you only need to move the tank and the turret will move with it.
Unfortunately with the .3ds file format this wasn't as easy.
To my knowledge the colladamax exporter is basically the most compatible out there, and supports animation perfectly.
I'll post the link to our project later.
The next project we'll be working on is getting models to import on demand, instead of being clumped together in one scene.
I faffed around with blender for a bit, but it screws up files imported to it (it reads c4d .dae files at about 4000% the size, whereas max doesn't) but the bewildering interface of blender made me give up before I had a real chance to check most things.
So, in conclusion, I still get to model and rig in my favourite modelling program (cinema). Then it's simply a case of running them through max9 to get them into papervision. Not an easy task when you're running an osx environment... but then again I know max very well and have finally found a new use for it.
Renderhjs is lucky. He's working on his own Flash 3D engine, and is even savvy enough to write his own 3D file parsers. So he can tailor his parser to whatever modeling program he uses. The rest of us are stuck struggling with the eccentricities of our software.
Like I mentioned before using those formats can:
- increase the data that has to be loaded sometimes up to 10x of what it would be using arrays or binary data
- lag because of the parsing time: what the engine needs to do is converting complex text string into logical arrays holding the vertex points, UV data, face array, vertexAnimation frames,..
I have a few custom fileformats developed for 3d engines- but often they were very specific designed - and making them work with Papervision or any other popular engine is another thing. I never played with them so I dont know enough + I dont have the time but any advanced as3 writer could implement it with a example code (PM me if you want it).
Right now I dont have the time to make postings about but that will happen eventually once I have a little more time on my hands.
In case you are interested in flash and 3d (not papervision, just pure flash) some of my flashkit postings:
3d engine kit (UV mapping Version 2)
http://board.flashkit.com/board/showthread.php?p=4103573#post4103573
3dsmax ASE format:
http://board.flashkit.com/board/showthread.php?t=720250
slicing triangles (UV mapping Version 1)
http://board.flashkit.com/board/showthread.php?p=3818672#post3818672
maxscript for flash
http://board.flashkit.com/board/showthread.php?t=757034
3d binary format for flash
http://board.flashkit.com/board/showthread.php?t=759766
Hey guys Ive been doing some experiments in papervision lately and got 2 models in there one on top of the other but where the objects intersect there is some wierd flickering polygons and zfighting is there a method to combat this?
most flash 3d engines have rather simplified z-depth soring mechanics. Away 3d (at first based on papervision but went its own way somehow)
http://away3d.com/
has as far as I know a more complex BSP tree depth sorting/clipping appoach which will cost a little bit more CPU waste but it does a better job of intersecting objects.