Help!!! 
Author Message
 Help!!!

Where can I find freeware VRML97 exporter for 3D Studio Max?

thanx in adwance.

Mariusz Pastor



Wed, 30 May 2001 03:00:00 GMT  
 Help!!!

Quote:

> Where can I find freeware VRML97 exporter for 3D Studio Max?

http://home.hiwaay.net/~crispen/vrmlworks/ -- click "Convert"
--
Bob & Kelly Crispen

"And I observe, when any Yahoo comes from London out of Curiosity [to]
visit me at mine own House, we neither of us are able to deliver our
Conceptions in a Manner intelligible to the other."


Wed, 30 May 2001 03:00:00 GMT  
 Help!!!
Thanks for the info but there is another problem - links on the Kinetix web
page http://ktx.com/3dsmax/html/vrml_exporter.html are dead.


Quote:

>> Where can I find freeware VRML97 exporter for 3D Studio Max?

>http://home.hiwaay.net/~crispen/vrmlworks/ -- click "Convert"
>--
>Bob & Kelly Crispen

>"And I observe, when any Yahoo comes from London out of Curiosity [to]
>visit me at mine own House, we neither of us are able to deliver our
>Conceptions in a Manner intelligible to the other."



Sun, 03 Jun 2001 03:00:00 GMT  
 Help!!!
I'm a bit new to this vrml thing but I'm doing a uni project where I have to
expand an existing VRML game.  We have a bit of a problem in that it goes
pretty slow with a big window.  I was wondering if there is any way you can
mention in the VRML code that you want to use pixel doubling (ala Doom,
Quake etc.).  I'm using Netscape and making the window smaller makes it go
much faster but it doesn't look very good.

I would be grateful if anyone could tell if there any other general
techniques for making VRML go faster that wouldn't be involve too much
hassle.

Thanks,

    David Johnston

--
 _  _       _        _  _      _  _  _  _     __
|_||_)|\/|'| \  ()  | \|_||\ |/ _|_ |_)/ \| |(_
| || \|  | |_/  (\  |_/| || \|\_/|_ | \\_/\_/__)

....http://www.argonet.co.uk/armdanddangerous/



Sun, 03 Jun 2001 03:00:00 GMT  
 Help!!!

Quote:

> I'm a bit new to this VRML thing but I'm doing a uni project where I have to
> expand an existing VRML game.  We have a bit of a problem in that it goes
> pretty slow with a big window.  I was wondering if there is any way you can
> mention in the VRML code that you want to use pixel doubling (ala Doom,
> Quake etc.).  I'm using Netscape and making the window smaller makes it go
> much faster but it doesn't look very good.

> I would be grateful if anyone could tell if there any other general
> techniques for making VRML go faster that wouldn't be involve too much
> hassle.

I've published a small article on the subject, but so have lots of
other people.  http://home.hiwaay.net/~crispen/vrmlworks/ -- click
Postproduction.
--
Bob & Kelly Crispen

"And I observe, when any Yahoo comes from London out of Curiosity [to]
visit me at mine own House, we neither of us are able to deliver our
Conceptions in a Manner intelligible to the other."


Sun, 03 Jun 2001 03:00:00 GMT  
 Help!!!

Quote:

> I would be grateful if anyone could tell if there any other general
> techniques for making VRML go faster that wouldn't be involve too much
> hassle.

No, I don't believe so. However you can limit the hassle with good
planning (just like with anything else).

PLANNING FOR SPEED

Keywords: LOD, Script, VisibilitySensor (*Sensor),
Billboard, NavigationInfo, Illusions.

LOD: Level Of Detail. This is something you really want to know how to
use. LOD can make a very big difference on the speed, however the
downside is that you loose some on download speed. Use LODs for
everything. An underestimated use is for example on ElevationGrids.
Instead of having one giant, use several small once and LOD them. There
are also (more content related really) some nice tricks you can do with
LODs to make special effects, but that's another story.

Script: ECMA vs Java. This is something that recently have been
confirmed can make a big difference. When to use it though isn't really
clear to me yet, so I leave it up to others to answer. Also there are
some parameters like directOutput and mustEvaluate that you should
carefully study. Use scripts together with sensors to turn stuff on and
off when you don't need it. A field you should always start with when
you make a new Script is the "enabled" field. Always give the
opportunity to turn a script off when it isn't needed.

VisibilitySensor (*Sensor): Sensors have to evaluate every frame (just
like anything else) and if don't need a sensor active be sure to turn it
off. An example is to have a VisibillitySensor turn on a Proximity |
Touch Sensor which in its turn triggers a TimeSensor. Then it is only
active when you really can use it. Warning on the Proxysensor though,
because you might get into trouble when you "back" into one that is
controlled by a VisiblitiySensor.

Billboard: This really should be under the "illusions" keyword. However
it's so useful I thought I'd give it its own section. Billboards are
very good to you if you are working with round shapes on long distance
(not necessarily long). I don't think you need a great imagination to
understand the difference of doing a full scale tree (where I found
Billboards most widely used) instead of having a single polygon (feel
free to triangulate it also) with a texture on it. Another nice way of
using billboards is of course for signs, but that's another story.

NavigationInfo: You asked about pixel doubling. Now, we don't have that
in VRML in the same way Doom and the alike have. Some would call pixel
doubling cheating, I would call it product specific (meaning I would
like have that possibility). VRML is a general file format for 3D on the
web. So, what has this to do with NavigationInfo? Well, very little, but
you have a field in there called visibilityLimit which you can use to
limit how far you see. However the line "Geometry beyond the
visibilityLimit may not be rendered." to me could mean anything.

Illusions: This is for me where VRML stands today. If you are developing
for Internet and don't know what hardware your visitors use you really
have to work on this skill. Just as the above tree example things are
best done in low-poly or with some tricks. This is unfortunently
something that is pretty hard to learn from tutorials (I've always
wanted to write one about it) since there aren't exactly any about it.
Illusions is often what makes one world different to another. No
compression utility I know of can compress your world as much as you can
do with a little creativity.
Illusions doesn't need to mean that you can't do hi-poly objects. The
two keywords mostly connected in this mail are in my opinion LODs and
illusions. The reason should be fairly obvious - LODs create illusions.
You can build very big worlds (like game scenes) if you use LODs wise
without for that reason giving up on the details.

Of course this isn't where it all ends. I've saved the best (nerdiest)
tips for last. Use a very slow PC when you develop and do it by hand :)
Use modelers only for geometry creation and always run them trough some
sort of optimizer before you use it. Get to know your optimizers! Re
slow PC. At least preview it on a slow PC before going public with it.

A final note about speed vs speed vs detail.
One of the worlds (yeah, ForestWorld) I've created has a lot of hits on
it. Thousands of people have seen it and I got a lot of feedback on it.
I don't believe that the reason for this is that it's nicer than others
stuff it's just that it's a pretty big world (no real interaction) that
people actually CAN SEE and experience. It's very fast to download
(since it's more or less build by scripts) and it's very fast to render
(since I did a lot of planning for it). The point I'm trying to make
(can never be said enough) is that if you don't make it small nobody
will see it, and why publish it if you don't want people to see it?

/Niclas
--
Niclas Olofsson           Ume? University, Sweden
Pedagoggr?nd 1A-210       Student, Dep. of Computing Science

                          http://www.acc.umu.se/~gurun
                          http://www.geometrek.com
--
"En seglare ber inte om medvind, han l?r sig segla"



Mon, 04 Jun 2001 03:00:00 GMT  
 Help!!!



Quote:

>> I would be grateful if anyone could tell if there any other general
>> techniques for making VRML go faster that wouldn't be involve too much
>> hassle.

Get a good 3-D card; and either turn "collision testing" off or use proxy
statements to simplify the collsion testing.  This will do a _lot_ for the
speed problem.

A warning though: WorldView's proxy testing is totally worthless, pure
bug-bait; Cosmo's proxy testing is (according to their bug notes) crippled
but still somewhat useful.

Quote:

>No, I don't believe so. However you can limit the hassle with good
>planning (just like with anything else).

>PLANNING FOR SPEED

>Keywords: LOD, Script, VisibilitySensor (*Sensor),
>Billboard, NavigationInfo, Illusions.

You missed "anchors" - speed the world by subdividing it into a set of
smaller worlds and then jump between them with anchor statements and
mouseclicks.  This is definitely a low-hassle method.

Quote:
>An underestimated use is for example on ElevationGrids.
>Instead of having one giant, use several small once and LOD them.

Interesting!  You use Cosmo, right?  This method didn't help me much when I
tried it since the memory load for elevation grids is, typically very large.
Actually, the browser need only do a 130x130 grid, more or less, to meet the
spec.  blaxxun is the only browser I've tried that Transforms large grids
quickly.  (Regarding grids: Cosmo is ok, and WorldView should be taken
behind the barn and shot.)  So the speed issue took a backseat to memory
usage when I tried this method with WorldView.

Quote:
>There
>are also (more content related really) some nice tricks you can do with
>LODs to make special effects, but that's another story.

>Script: ECMA vs Java. This is something that recently have been
>confirmed can make a big difference.

ECMA?  Hmmm...  I tried this a few months back, with Cosmo, and it wouldn't
load at all.  Javascript works well with Cosmo (except for a peccadillo
regarding the alternate use of "," or " " or ";" to end Javascript code
lines).  ECMA (which I extracted from the spec. on the web) simply didn't
parse and I had to rip it out and restore the Javascript.

Quote:
> When to use it though isn't really
>clear to me yet, so I leave it up to others to answer. Also there are
>some parameters like directOutput and mustEvaluate that you should
>carefully study. Use scripts together with sensors to turn stuff on and
>off when you don't need it.

Yep, and keep the scripts simple.  A script that tests a series of buttons,
for example, can get surpisingly slow and, more importantly, the interrupts
can create jerky motion.

Quote:
>A field you should always start with when
>you make a new Script is the "enabled" field. Always give the
>opportunity to turn a script off when it isn't needed.

Good, thanks!

Quote:

>VisibilitySensor (*Sensor): Sensors have to evaluate every frame (just
>like anything else) and if don't need a sensor active be sure to turn it
>off. An example is to have a VisibillitySensor turn on a Proximity |
>Touch Sensor which in its turn triggers a TimeSensor. Then it is only
>active when you really can use it. Warning on the Proxysensor though,
>because you might get into trouble when you "back" into one that is
>controlled by a VisiblitiySensor.

Hey, thanks again!

Quote:
>Billboard: This really should be under the "illusions" keyword. However
>it's so useful I thought I'd give it its own section. Billboards are
>very good to you if you are working with round shapes on long distance
>(not necessarily long).

"round shapes"?  Could you elaborate this please?

Quote:
> I don't think you need a great imagination to
>understand the difference of doing a full scale tree (where I found
>Billboards most widely used) instead of having a single polygon (feel
>free to triangulate it also) with a texture on it. Another nice way of
>using billboards is of course for signs, but that's another story.

Be sure to use a graphic with transparency to color the tree; otherwise the
spaces between the brances are (typically) gray which, frankly, looks dorky.

Quote:

>NavigationInfo: You asked about pixel doubling. Now, we don't have that
>in VRML in the same way Doom and the alike have. Some would call pixel
>doubling cheating, I would call it product specific (meaning I would
>like have that possibility). VRML is a general file format for 3D on the
>web. So, what has this to do with NavigationInfo? Well, very little, but
>you have a field in there called visibilityLimit which you can use to
>limit how far you see. However the line "Geometry beyond the
>visibilityLimit may not be rendered." to me could mean anything.

>Illusions: This is for me where VRML stands today. If you are developing
>for Internet and don't know what hardware your visitors use you really
>have to work on this skill.

You also need to know the browser your visitors are using.  If it isn't
Cosmo then lock the door.

Incidentally, WorldView defines colors in a non-standard way so nothing
looks the same there as when viewed with Cosmo.  Cycling through a range of
colors for an object gives very funky results unless the colors are very
carefully chosen (with WorldView).  And blaxxun browser loads image files
onto elevation grids erroneously: images that work with Cosmo and WV will
look flipped (around the Z axis, I think) with blaxxun.  Blaxxun doesn't
color grids properly either in my experience.  And WV doesn't (and won't)
implement the "gravity" option.  Both Cosmo and WV fail to display objects
with a size of zero, and present error messages instead, even though this is
completely legal according to the copy of the vrml spec. I checked.  (The
original version of WV does implement this though, but this excellent way of
displaying or hiding objects in a scene is now unavailable with WV.)  Etc.
Etc. Etc.

Actually, if you want your special effects to work in several different
browsers, you will have to use a fairly small subset of vrml.  Very limited
set, really, when you also accomodate the various differences at the coding
level (like the proxy question).

Since browsers can be loaded quite easily, it's better to require visitors
to use the browser you've chosen.  Otherwise a lot of them will be unhappy
no matter what you do.

 Just as the above tree example things are

Quote:
>best done in low-poly or with some tricks. This is unfortunently
>something that is pretty hard to learn from tutorials (I've always
>wanted to write one about it) since there aren't exactly any about it.
>Illusions is often what makes one world different to another. No
>compression utility I know of can compress your world as much as you can
>do with a little creativity.
>Illusions doesn't need to mean that you can't do hi-poly objects. The
>two keywords mostly connected in this mail are in my opinion LODs and
>illusions. The reason should be fairly obvious - LODs create illusions.
>You can build very big worlds (like game scenes) if you use LODs wise
>without for that reason giving up on the details.

There's a catch to LODs; two actually.

First, the distance from the viewpoint to the LOD center is radial (i.e.,
activation occurs in a circular or spherical region; unfortunately, vrml
primative shapes don't include circles and rooms, etc., are typically
rectangular anyway.  So you have to include the adjacent rooms at high res.
when the occupied room is in that LOD state. This gets pricey.

Second, the activating distance is variable by default (the browser sets it)
and setting these by hand, to avoid weird jumping scenery.  Hand-definition
of these distances is a chore.  And some slack should be included in the
system as you write it because the new level won't load until after the old
one is removed (with WV anyway, in my experience).

Quote:

>Of course this isn't where it all ends. I've saved the best (nerdiest)
>tips for last. Use a very slow PC when you develop and do it by hand :)

Yep!

Of course, using a slow PC can prevent you from using the techniques that
give the _right_ results.  So this decision is a judgement-call situation.

Quote:
>Use modelers only for geometry creation and always run them trough some
>sort of optimizer before you use it. Get to know your optimizers! Re
>slow PC. At least preview it on a slow PC before going public with it.

Can you recommend an optimizer?

Actually, forcing computer owners to buy better hardware is a
well-established and respected part of the software business.  People who
can't afford better hardware don't have money to spend on your software
anyway; and if _everyone's_  programs ran quickly then wealthy people would
have one less reason to gloat and, frankly, the industry would crash like a
pregnant woman on skates.

Quote:

>A final note about speed vs speed vs detail.
>One of the worlds (yeah, ForestWorld) I've created has a lot of hits on
>it. Thousands of people have seen it and I got a lot of feedback on it.
>I don't believe that the reason for this is that it's nicer than others
>stuff it's just that it's a pretty big world (no real interaction) that
>people actually CAN SEE and experience. It's very fast to download
>(since it's more or less build by scripts) and it's very fast to render
>(since I did a lot of planning for it). The point I'm trying to make
>(can never be said enough) is that if you don't make it small nobody
>will see it, and why publish it if you don't want people to see it?

Neat!  Can we have the code, or will we have to "steal" it?  (Hey, just
kidding!)

The part about building it from scripts, to speed download, sounds nifty
though. Care to expand on that?

Quote:

>/Niclas
>--
>Niclas Olofsson           Ume? University, Sweden
>Pedagoggr?nd 1A-210       Student, Dep. of Computing Science

>                          http://www.acc.umu.se/~gurun
>                          http://www.geometrek.com
>--
>"En seglare ber inte om medvind, han l?r sig

...

read more »



Sun, 17 Jun 2001 03:00:00 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. help! f90.help help help help

2. ***HELP***HELP***NEED INFORMATION***HELP***HELP

3. HELP HELP HELP HELP

4. HELP HELP HELP HELP

5. Ord Function HELP Please HELP HELP HELP

6. help help help help!!!!!!!!!!!

7. (HELP (HELP (HELP (HELP))))

8. HELP: HELP: HELP: HELP: Online-manual on Expect

9. Help Help Help

10. TopSpeed - ODBC 3.1???? HELP HELP HELP

11. HELP - HELP - HELP

12. HELP HELP HELP - round function error

 

 
Powered by phpBB® Forum Software