Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Corrupted Marine

Risen3D Problem

Recommended Posts

Use GZDoom or Legacy, much easier to make 3D floors. (no stupid hexadecimal crap just to make a 3D floor)

Plus, Risen has been discontinued due to issues I dont care to link to at this moment.

Share this post


Link to post

So its started up again?

I thought the guy deleted all of the source files because of some lame internet dispute...

Share this post


Link to post

Yes, Risen3D is alive and well. :)

@Corrupted Marine - It looks like the middle of your floor is missing.

Have you downloaded Sitter's tutorial for 3D floors ?

http://md2.sitters-electronics.nl/3dfloora.html


If that doesn't help you might like to post the wad on rapidshare or somwhere so I can take a look at the problem in an editor.

Share this post


Link to post

Yes, I have used sitters tutorial for this. But heres what is happening:
The bridge is a 3d floor, and the supports are 3d lines. So, I have 3d objects inside another 3d object, and thats probably the problem. I know that GZDoom and Legacy can have 3d sectors in other 3d sectors. ex: a box on a 3d floor.
In my situation, I have my bridge, and it looks just fine by itself. Then I put the supports in as 3d lines. Thats whats messing up my bridge. If I only have 1 support, it looks fine, but when I put 2 supports, there is a hole in my bridge between the two supports. And then I put all 6 and there is a huge hole between all the supports.

@hawkwind: Would you like me to PM you the dl link for this so you can look at it? I would really appreciate it.

Share this post


Link to post

@Steeveeo: I've noticed that almost every single time you respond to a port-specific question, your universal response is something along the lines of "Don't use that, I think its not as good as port X", and it is starting to get really, really annoying.

If I had a problem with my car and went into a garage and asked for help; I certainly would not appreciate (or expect) being told, "You know, I think they make really nice cars at <insert car manufacturer here>, you should use one of those".

Share this post


Link to post
DaniJ said:

@Steeveeo: I've noticed that almost every single time you respond to a port-specific question, your universal response is something along the lines of "Don't use that, I think its not as good as port X", and it is starting to get really, really annoying.


Dude, I only say it when its true.

Notice I said that GZDoom and legacy were easier to make 3D floors for.

Thats just because (last time I checked) Risen3D uses some headache inducing hexadecimal crap to create 3D floors and slopes. Whereas GZDoom just uses reference sectors to create 3D floors and slopes. Therefore it is much easier to do!

And also, ports, unlike cars, do not cost thousands of dollars, just some time on the net and one tiny iota of computer knowledge to get the thing running!

Share this post


Link to post

Well that really doesnt matter, Im more worried that you're following me around and reading all my posts... ¬_¬

Anyway, to prevent further derailment of this thread, back on topic now.

It looks like you forgot to put a hex value around the support and cause the floor around it to disappear.

I may be wrong however, since I get a headache whenever I try to mess with Risen 3D floors, and never got them working like they shouldve.

Share this post


Link to post

[QUOTE]Corrupted Marine said:


@hawkwind: Would you like me to PM you the dl link for this so you can look at it? I would really appreciate it.

Sure ! PM me.

@Steeveeo - It's not hexadecimal crap as you put it. Those figures are basically the distance from the map floor height to the floor of the R3D floor and the thickness of the floor itself in map units.

Share this post


Link to post

which is in hex format (ie 112233 values preceded with a symbol, usually a # but in risen its $ last time I checked)

Share this post


Link to post
hawkwind said:

@Steeveeo - It's not hexadecimal crap as you put it. Those figures are basically the distance from the map floor height to the floor of the R3D floor and the thickness of the floor itself in map units.



It's hexadecimal and a rather crappy way of doing things. So one could consider it 'hexadecimal crap'. :P

Share this post


Link to post

Well.... GZDoom really is MUCH easier to make 3d floors and slopes. etc.

I'm curious: Are md2 models supported in GZDoom?
The project that i'm working on requires 3d floors, slopes, md2 support, dynamic lights, etc. Basically i'm trying to make an entirely 3d game using the Doom engine.

Share this post


Link to post

@Graf Zahl and Steeveeo

I see now why you might think it is hexadecimal, seeing A-F is used. These are purely used to differentiate between R3D definition types.

Please read R3D_Structures.txt - in distro - for a full description.

Share this post


Link to post
Corrupted Marine said:

So, does this mean that I can have models, just not animated ones????

Of course they animate. Interpolation just means very smooth animation.

Share this post


Link to post
Corrupted Marine said:

So, I have 3d objects inside another 3d object, and thats probably the problem.

Doubtful, as you can have 3Dfloors on top of 3Dfloors in Risen. I know because I've done it. It's a PITA though.

Corrupted Marine said:

I'm curious: Are md2 models supported in GZDoom?

Yes, it does support MD2 models; however you can use static models only, last time I checked.

Corrupted Marine said:

So, how smooth are we talking here? Like Quake 1 smooth? lol

In engines that interpolate, the smoothness depends on your current framerate.

In engines that don't interpolate, your models will have the same amount of animation that Doom's original sprites have.

Share this post


Link to post

In engines that don't interpolate, your models will have the same amount of animation that Doom's original sprites have.

Not necessarily, it depends on the implementation.

In Doomsday (and thus Risen3D) if you disable vertex position interpolation you will notice that many models are still animated fairly smoothly. This is because you are not limited to the number of frames used in the original sprite frame sequence. Any number of model frames can be mapped to the original DOOM sprite frame sequence, for example a 4 sprite frame animation could be replaced with 16 model frames.

Share this post


Link to post
DaniJ said:

This is because you are not limited to the number of frames used in the original sprite frame sequence. Any number of model frames can be mapped to the original DOOM sprite frame sequence, for example a 4 sprite frame animation could be replaced with 16 model frames.

Not wanting to get too far off-topic, but something I'm very interested to know: if models were limited to the sprite frame sequence, could they still look good?

Share this post


Link to post

If there is no interpolation then I would say positively not, it would look rather ridiculous.

With interpolation in place, the situation is not quite as bad. However, it is an impossible task to obtain any kind of weighting behind movement (especially short/fast) in an animation due to the miniscule number of frames available to play with. The result will be a very artifical looking animation (imagine the "robot dance").

If using an approach similar to that used by Doomsday in combination with a model containing a decent number of frames; there is far less need for interpolation (except when tweening between the frames of two different animation sequences).

Share this post


Link to post

That is an excellent bridge .... :)

All credit for solving the problem really goes to Graham Jackson. I just informed him of the problem.

Please keep the community informed on any progress with this wad. There are not many R3D wads out there .....

Share this post


Link to post

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×