Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Omniscaper on June 16, 2005, 07:42:54 pm
-
(http://www.game-warden.com/bsg/staff_images/WIP%20Gallery/DSWip.jpg)
Other screenshots of this WIP http://www.hard-light.net/forums/index.php/topic,33322.0.html
-
One thing at a time, man! You're liable to get Raa Syndrome!
-
opperational.
let me look through the parseing code...
ok, you need to add
$detail_box:
to an object's properties followed by a 1 if you want that subobject to be drawen when the player is inside the detail box or -1 when you want it to be drawen only when you are outside the box.
then
$box_min:
and
$box_max:
each followed by the min and max x,y, and z dimentions of the box in the subobject's reference frame.
you can (and I'd realy like to see it) make recursive detail boxes, were you make child detail as childeren subobjects.
like you have a building on the death star, then as a child of that a bunch of deflector arrays and stuff, and as childeren of that you have a bunch of girders and reenforcement beams and conectors. if you do it right you could probly get a fully detailed death star in game with hundreds or thousands of subobjects, but only about a dozen of them ever even get evaluated for posable rendering.
-
Working on one model for extended periods of time will drive me to the bottle. Besides... I do have a Star Wars icon under my name. I may as well start representing.
I think a 120 km diameter Deathstar may be a bit too much. It takes roughly a minute to reach the surface from the distance posted above under 64x time compression. And the model shown is only 22km in diameter.
-
Originally posted by Bobboau
opperational.
let me look through the parseing code...
ok, you need to add
$detail_box:
to an object's properties followed by a 1 if you want that subobject to be drawen when the player is inside the detail box or -1 when you want it to be drawen only when you are outside the box.
then
$box_min:
and
$box_max:
each followed by the min and max x,y, and z dimentions of the box in the subobject's reference frame.
you can (and I'd realy like to see it) make recursive detail boxes, were you make child detail as childeren subobjects.
like you have a building on the death star, then as a child of that a bunch of deflector arrays and stuff, and as childeren of that you have a bunch of girders and reenforcement beams and conectors. if you do it right you could probly get a fully detailed death star in game with hundreds or thousands of subobjects, but only about a dozen of them ever even get evaluated for posable rendering.
Ok, it will take me a while to decipher what you just said, but I'm on it! Danke!
BTW is it present in all the recent test builds?
-
yeah, it's been in for a long while.
btw, you'll be the first person to actualy test the defineable box
-
Nice stuff!
We really need a more comprehensible way of keeping track of the latest features. Most of the time, only the coders know all of whats in the latest builds. I'd be willing to bet there is a great deal of features that nobody in the public knows about still.
-
Originally posted by Bobboau
opperational.
let me look through the parseing code...
ok, you need to add
$detail_box:
to an object's properties followed by a 1 if you want that subobject to be drawen when the player is inside the detail box or -1 when you want it to be drawen only when you are outside the box.
then
$box_min:
and
$box_max:
each followed by the min and max x,y, and z dimentions of the box in the subobject's reference frame.
you can (and I'd realy like to see it) make recursive detail boxes, were you make child detail as childeren subobjects.
like you have a building on the death star, then as a child of that a bunch of deflector arrays and stuff, and as childeren of that you have a bunch of girders and reenforcement beams and conectors. if you do it right you could probly get a fully detailed death star in game with hundreds or thousands of subobjects, but only about a dozen of them ever even get evaluated for posable rendering.
is pcs or the max converter even capable of converting something like that? sounds to me like it would grind a them to a hault on something the scale of a death star.
how about a planetary rendering engine where you create square sections of terrain or buildings or whatnot, and map them to a spherical grid via a table. you would create a planet by tieling a sphere, that means you would have to model so that your tiles may be repeated seamlessly. o define a distance model, (like the model above) above that fills in for the planet from a distance. im not sure how to handel the poles, you could section it like a soccer ball, which would require hexaganal (pentaganal?) tiles, but that would impose more modeling/programming chalenges. the sections would each need to have their own lods and turret support. it would also decrease the amount of resources needed because tiles could be used many times.it would also reduce the amount of data needed. there are many mods that could binifit from the system.
speaking about features, vwep still is not working. :D
-
Funny. I pulled XWA out of its cobwebs and playing it I wished that it were on SCP. Well. There's that :D
-
I know this may be wishfull thinking, but is there anyway to have the detail box "fade" instead of "popping up" into existence ? I think that would be the ultimate way to handle a Death Star.
-
My first test seemed to have failed, but perhaps my subobject properties were wrong. I am using the 5/22/2005 build from the "Recent builds" thread.
Reguardless, this is perhaps quite a milestone in my conversion history. I successfully converted and played a WHOPPING 178,120 polygon Deathstar.
(http://www.game-warden.com/bsg/staff_images/WIP%20Gallery/DSWip8.jpg)
The framerate does suffer and the load time was rediculous. Perhaps a 3 minute load time. My subobject properties are as follows:
$detail_box:1
$box_min:1,1,1
$box_max:20,20,20
I wasn't sure how the numbers translated (or didn't translate) as distance.
-
now do those go in the subobject properties or the table?
*edit*
duh, the answer was right there in front of me
[/idiot]
-
I think the whole popping could be fixed with a more 'gradual' LOD-ing.
Which AFAIK is more work...
...though this time a reverse-top-down approach would be good.
Make the whole thing in all its splendor - then start to break it down.
Zoom out and check when the details are lost - cut the lost stuff.
Go back and check when things blurr in - cut stuff out, or make it part of the texture.
This could be a lot of work - but with enough LODs - and these mini tied in superdetail boxes - you can have a pretty seamless relevation of detail.
-
Bobboau, I got the detail box working after some sifting through some old threads. I didn't have a space between "$detail_box:" and the "1"
The custom box boundaries are still not working, I came across a post where you mentioned the syntax:
$box_min: min_x ,min_y , min_z
$box_max: max_x ,max_y , max_z
Is that the EXACT syntax? If so, where do I pluggin the numbers and what do those numbers represent, meters?
-
you seem to be misunderstanding what min and max are, if you want the object to only draw when in a 20 meter box of the object (20m in all directions) you need to specify max as 20, 20, 20, and min as -20, -20, -20
-
The detail boxes are still not working with custom box properties. The subobjects don't render at all. I inputed the proper syntax as you said.
Do those numbers refer an offset to the OBJECTS's center or the objects desginated pivot point? All the subobjects' pivot points are located at the Deathstar's absolute center. (those are the ones rendering once within its perimeter) Its the same location where ALL other subobjects' pivot points are.
I moved the pivot point of the objects to the objects' center and those are not rendering at all (with or without custom box properties)
If you could explain how it renders in default, I can hopefully figure out what numbers to use in the custom properties.
I use Styxx's latest 3dsmax exporter. I've already experienced MUCH crashes with an object with this many subobjects. I have 204 subobjects already.
Under examination with PCS, the bounding boxes look ALL alike. This trial and error method is KILLING ME!!! I need more info! :)
-
ok, you have an object, this defines two points, two corners of a cubeoid, one intersecting all the minimum dimentions, another intersecting all the maximum dimentions.
it's quite posable that the parseing code simply does not work, (it might be easier for you to make a box in your modeling program and apply the invisable texture to it, and use the no colide invisable flag), just make sure there in the same subobject (or less effecently but functional, the visable geometry is a child of the box object)
what it does is it takes the position of the eye relitive to the object beiing evaluated, and on an element by element, basis it makes sure none of the values are bigger than the max, or less than the min, if any are it won't render
-
Sigh.... is the no collide flag a TBL entry or a subobject property? What is the exact syntax? I'll try the invisible box method, though if it is a table entry, it will be a pain to put HUNDREDS of those entries in the ship.tbl. I've spent WAY too much time on this Star Wars side project.
I still found it ODD that when I do put the pivot point of the object to its center, it would not render at all. Even without the custom box properties. PCS sees it just fine, and its where its supppose to be.
-
Originally posted by Omniscaper
Sigh.... is the no collide flag a TBL entry or a subobject property? What is the exact syntax? I'll try the invisible box method, though if it is a table entry, it will be a pain to put HUNDREDS of those entries in the ship.tbl. I've spent WAY too much time on this Star Wars side project.
It's a flag on the ship table but you'll only need to add it once. It basically makes it so that you can fly through any surface on the model which is textured with a texture called invisible.
Take a look at the knossos if you need a further example.
-
For future reference Omni, pivot points should always be in the center of a subobject unless REQUIRED to be otherwise by rotational properties. It effects a number of things, including the lead indicator and (if it's too badly screwed up) the bounding box in-game. There could be issues with an object as large as the death star, though, so you may want to try experimenting with something smaller.
-
Though I had to create invisible boxes to force the rendering of the subobjects to be further away.....
BEHOLD BOBBOAU's SUBOBJECT LOD's IN ACTION!!!
(http://www.game-warden.com/bsg/staff_images/WIP Gallery/DSWip10.jpg)
More sceenshots here: http://www.hard-light.net/forums/index.php/topic,33322.0.html
Bob, recursive detail boxing is also in use!!!
Total polygon count... a WHOPPING 181,840 polygons!!!
Lets sets see if this 8 year old game can handle a MILLION....... :)
-
Something to keep in mind, I think there are two flags, "no collide" and "no collide invisible" - you want the latter.
-
it'll handle a million easily.
and are you sure the trench was that equator thingy? I always had the feeling it was just between the seams of two absurdly huge armor plates.
-
And you're obviously right, since the trench ends with the... thing to bomb. The equator trench is where the hangars are, and goes circa around the death star.
It's much deeper and larger (well, in certain shots, it's not nearly as deep as it should be, but consistency, you know, especially in SW...)
-
Originally posted by Omniscaper
(http://www.game-warden.com/bsg/staff_images/WIP Gallery/DSWip10.jpg)
Sweet mother of mercy.
You're off your nut.
And i mean that in a good way!
-
Going. To. Crash. FRED.
It's nice to see someone finally exploring this feature and all, don't get me wrong. But the subsystems/mission problem is bound to show up sooner or later.
-
Fred seems fine to me. I already Fredded a couple of test missions. Its just a pain to work with such a large model. Putting nav points along the trench is quite difficult.
(http://www.game-warden.com/bsg/staff_images/WIP Gallery/DsFred.JPG)
-
detail boxes use no subsystems, so that isn't an issue.
-
Question is, can the same property be applied to turrets. DS hsa hundred of them. If detail boxes cannot be applied to turrets, then I will have to greatly reduce their numbers.
-
yeah, they can
-
Bob, is it safe to assume that the subobject "custom" bounding box is not working? I've tried a number of combinations, from having the subobject's pivot centered on itself or having it centered on the main object's center. No matter what I do, the subobject keeps rendering at its perimeter or not at all.
Making an invisible box to act as render bounding boxes is proving to be cumbersome in the converting process. Though it is not rendered in game those invisible boxes are causing havok on Styx's 3dsmax pluggin. Perhaps its the additional polygons thats causing conversion crashes?
It would be so much easier for me and the pluggin if the custom bounding properties would start working. Its quite a time consumer to make seperate invisible boxes to be parented and positioned to the target subobject. Can you give me an example of a working syntax? Perhaps its my syntax. Then again, has the custom bounding box been successfully tested?
-
it's probly the code screwing up.
I would think that haveing to type in all those values without any graphic feedback would be more dificult. maybe we need to talk to styxx about it.
-
Originally posted by Bobboau
it's probly the code screwing up.
Make sure that it's not your code screwing up. ;)
-
well he was the first person to ever test it, if I ever get around to codeing again I'll fix it.
-
Going nuts now. The Deathstar refuses to convert beyond the 200k poly level. Is there a limit to the number of subobjects a model can have? At the moment I'm at 300 subobjects. A fully greebled DS will exceed that number obviously.
-
no limit acording to the file specification.
-
Kool, crossed out that as the source of the crash.
I did find something strange while experiemnting with your subobject custom bounding box properties. I think I know now why it hasn't been working. When I open the model with modelview, the numbers for each subobject's bounding boxes are much larger than I expected. The numbers seem to take into account its absolute position in relation to the parent object's center. If this is the case, that mens I would have to make custom numbers for all subobjects. That sucks! I thought each subobject's bounding box numbers would be relative to its own center and not of the parent object.
Before I converted the test model, I positioned all of the subobject's pivot points to center on the subobject, not the main object's center.
BLARRGGGGG